Convert TextMapSetters and TextMapGetters to enums

[iNikem]

All effectively singletons setters and getters were converted to enums. A couple of them which accept a list of propagators for semi-manual propagation could not be converted and so remained.

[trask]

I'm not sure the singleton-ness is used in the new instrumenter api?

[iNikem]

I'm not sure the singleton-ness is used in the new instrumenter api?

WDYM by "used"?

[trask]

I'm not sure the singleton-ness is used in the new instrumenter api?

WDYM by "used"?

we only use the singleton references once (when constructing the instrumenter), so doesn't seem like any advantage to them being singletons over being normal objects?

[iNikem]

Are there any downsides?

[iNikem]

Based on #995 (comment) and the next several comments, I understood that we want to convert these setters and getters to enums. @anuraaga is clearly in favour of this change. Remaining @open-telemetry/java-instrumentation-maintainers , do you vote in favour, against or abstain?

[trask]

Based on #995 (comment) and the next several comments, I understood that we want to convert these setters and getters to enums

that discussion predated the Instrumenter API

@anuraaga is clearly in favour of this change. Remaining @open-telemetry/java-instrumentation-maintainers , do you vote in favour, against or abstain?

I would just ask you or @anuraaga to explain the reason for making them singletons, maybe it's obvious, but I am missing it. Then I would be happy to vote in favor.

[anuraaga]

I guess the main reason would be just to make sure they're singletons - for example, while there often isn't a use case, a user could initialize a *Tracing module multiple times for some reason, and there is some benefit then to keep things singleton where possible. In many cases, there won't be a difference though, but it probably doesn't hurt to guarantee singleton just in case.

[mateuszrzeszutek]

Remaining @open-telemetry/java-instrumentation-maintainers , do you vote in favour, against or abstain?

I think I'd like to abstain - it seems to me that this is purely a stylistic choice; the setter classes perform exactly the same no matter how many instances exist. I don't mind making them all singletons if we decide so.