Define some classes internal

[pavolloffay]

See #253 (comment)

Some classes should be moved to "internal" package to avoid public use.

[yurishkuro]

Looks like a meta issue. Do we have an inventory of what should be moved?

[jpkrohling]

Making this inventory would be part of the task. In general, I would say that anything non-core should be marked as "private". I would also take a white-listing approach for things in the core: place everything under "internal", and then move them out based on their expected consumption:

• io.jaegertracing -- things meant to be used by applications directly, like the Configuration object
• io.jaegertracing.spi -- service provider interfaces, like senders, reporters, ...
• io.jaegertracing.internal -- for things that are meant to be consumed only by our own components, like utility classes

[mabn]

When I wrote wrappers for jaeger there was one case where I had to use a package-protected method: SpanContext.isDebugIdContainerOnly().

Basically when passing wrapped SpanContext to a SpanBuilder I needed to be able to tell if it contains proper IDs or not.

From my point of view an ideal solution would be some better way to pass extra information from Extractor to SpanBuilder.start(). Right now the only ones are:

• put something temporarily into the baggage
• or set debugId flag (which cannot be read)

One more issue I had is that my traceId/spanId are strings and converting them to long looses information, so I had to put my IDs into the baggage for a while anyway - to store them for later propagation to other services.

Maybe it would make sense to create ExtractedSpanContext - a subtype of SpanContext which contains a map with extra properties?

I could avoid all these by not implementing Extractor interface, never delegating to jaeger's extract and instead writing my own extraction - it would be actually much simpler because then I could use my own SpanContext type.