Rename HTTPText to TextMap Propagator.

[carlosalberto]

Fixes #317

HttpText is renamed to Text for the Propagator component.

I remember we barely discussing the possibility of renaming it to AsciiText instead (or similar), but wanted to try out Text first, as it's simpler, but I'm open to feedback ;)

[Oberon00]

I would name this "TextMapPropagator" or "TextHeaderMapPropagator" to emphasize that it operates on a map of key/value pairs as opposed to simply returning/accepting a string (which might be the interface for the binary propagator).

[carlosalberto]

For the record, TextMap was the name we used back in OT ;)

[bogdandrutu]

@carlosalberto @Oberon00 happy with TextMap.. as long as it is very clear what are the expectations for the keys and values in therms of encoding (ascii, utf-8, utf-16, url encoded, etc.)

[bogdandrutu]

@carlosalberto ping

[carlosalberto]

Renamed this to TextMap - should we list the keys/values encoding restrictions in a follow up?

[bogdandrutu]

Would prefer now because before they were in the name otherwise this is a downgrade

[Oberon00]

I'm fine with this name.

I don't think we need to put an encoding in the name. If we want to have an ASCII-only propagator, we can do this strongly typed, but we don't have to. We could have a getAsciiTextMapPropagator and getTextMapPropagator on the Propagators class/interface both returning an instance of TextMapPropagator.
If we implement this strongly typed, I suggest writing the spec in such a way that you can implement AsciiTextMapPropagator as an empty interface deriving from TextMapPropagator.

[carlosalberto]

@bogdandrutu Added a note with a MUST - wondering about it after @Oberon00's comment. For reference, we had something like this as well in OpenTracing, although more of a suggestion (in order to increase compatibility).

To me, the most common case is still HTTP headers, so I'd vow to stick to ascii. For other encodings, the user should be able to (hopefully soon) use a Binary propagator instead ;)