Fixes bug where debug did not imply sampled

[codefromthecrypt]

It is true the b3-propagation spec suggests debug implies sampled.
This leniently parses a missing X-B3-Sampled header as long as
X-B3-Flags: 1 is present.

Fixes #661

[tgeens]

What is the reasoning to handle this in the builder and not in the sampled() method ?

Extraction from the B3-headers should work correctly with this PR, but I expect this assertion would fail:

assertThat(context.toBuilder().debug(true).sample(null).build().sample()).isTrue();

[codefromthecrypt]

What is the reasoning to handle this in the builder and not in the sampled() method ?

because the context is immutable, so there's no need to conditionally consider this at runtime (the extra logic isn't needed). debug is very edge case and it is also distracting to have the most used code (sampled) have to make decisions for something rarely used and also implies a fixed decision. So it is mainly about what we are optimizing for.. I don't like optimizing for the odd things.

Extraction from the B3-headers should work correctly with this PR, but I expect this assertion would fail: assertThat(context.toBuilder().debug(true).sample(null).build().sample()).isTrue(); debug is already a very edge-case feature, one that almost no-one uses.

When it is used, it is often used alongside the sampled flag. for example, the chrome plugin does this.. that's why this issue itself wouldn't hit many. So, let's keep in mind the likelihood of it ever being set in this way. I added propagation tests, for the off-chance. Now, in your test case, you are talking about a trace context manually changed, in a strange order, which is even more edge case.. For example, sampled isn't set to null after a decision is made. A decision is persistent in the trace once made. It basically doesn't make sense even if it made sense to manually change a context. Sorry this particular line is getting more attention than a lot of the codebase :) I'm going to stop explaining now and hope I answered.. still lots to do!