ZipkinHttpHeaders isn't quite right on flags

[codefromthecrypt]

Hinting from the below comment and an encoding bug I think flags needs to be revisited:

        public const string Sampled = "X-B3-Sampled"; // Will be replaced by Flags in the future releases of Finagle

The X-B3-Flags header back maybe 2012 or so was thinking about becoming more, but never did. Reasons including awkward overlap with sampled, and also it is mainly covering binary encoding concerns, not http ones. For this reason, back in the day, we documented X-B3-Flags based on how all the libraries worked, essentially 1 being the only valid value, which is the debug flag.

https://github.com/openzipkin/b3-propagation#debug-flag-1

Emitting bitset behavior will actually either restart traces or reset the sampling decision, so this should be changed fairly urgently to only send the header when debug is set and not otherwise.

See openzipkin/zipkin-go#53

[codefromthecrypt]

@nonspecialist mind having a crack at fixing this?

[nonspecialist]

@adriancole C# is really not my strong point (I only picked it up 2 days ago) but I'll have a crack at it

[nonspecialist]

@adriancole I'm looking for clarification on the B3 Propagation spec, and what should happen if X-B3-Flags is received with a value of 0. According to the spec:

Flags value	Sampled value	is valid?	meaning
1	0	no	debugging implies accept, Sampled should not be passed
1	1	no	as above
1	unset	yes	as above
unset	0	yes	do not sample
unset	1	yes	force sampling
unset	unset	yes	receiver to determine whether to sample
0	0	unspecified	presumably, do not sample?
0	1	unspecified	presumably, force sampling?
0	unset	unspecified	presumably, receiver to determine?

What's unclear is whether a sender should ever emit X-B3-Flags: 0 at all and if it does, is there an implication to turn off debugging even if the receiver has it turned on?

[codefromthecrypt]

I wouldn't interpret Flags 0 in any way except for the same as unset