Fixes bad parse of parent w/o sampling and backfills logging tests

[codefromthecrypt]

One case failed to parse, which is not-yet-sampled header that includes
a parent ID. This is malpractice, but shouldn't fail to parse. This
fixes it.

This also corrects the log statements for some things and tests them.

Coming out of envoyproxy/envoy#4712 (comment)

@zyfjeff noticed our logs were misleading on incorrect data like putting an exclamation point where a hyphen should be. I was lazy and didn't assert on logs.. now .. yeah will do that :P

Thanks to @zyfjeff cc @shakuzen

[codefromthecrypt]

this fails while I backfill all the things.. raised early as wanted to show how to do this

[codefromthecrypt]

ok done.. interestingly we did miss one case here, too

[codefromthecrypt]

cc @drolando @sfackler @fedj @dpsoft again.. just in case you copy/pasta'd an error

[drolando]

@adriancole I don't really understand what not-yet-sampled header or your example mean.
Is a b3 header containing {x-b3-traceid}-{x-b3-spanid}-{x-b3-parentspanid} (missing sampled flag) valid?

[codefromthecrypt]

It isn't really valid semantically. as if you haven't sampled yet, and you are incrementing parent ids anyway, there's a good chance the trace will be bad. However, it is well formed. That said I don't mind dropping as invalid considering it is dodgy. Incidentally, I thought someone at Yelp may have seen this cc @bplotnick

[codefromthecrypt]

I am not extremely creative, but one possibility for parent ID w/o sampled yet is someone doing log based IDs prior to entering zipkin. For example, if you had a few load balancers stacked. Again I don't think this is something tracers should think about.. the change here was more about the logging vs the edge case.

[bplotnick]

I can't remember specifically. Based on my concern here: openzipkin/b3-propagation#21, I might've been referencing one particular issue we had internally with an incorrect custom implementation (we've had a few such cases of custom internal implementations that have made mistakes by not following the b3 standard exactly). Or i could've just wanted more clarity on an ambiguity.

[codefromthecrypt]

Thanks for piping in @bplotnick FWIW I'm happy to be extra lenient for now. We can make a different change to be un-lenient.. the former code said it addressed this and didn't hence me calling it a bug. the pattern is still questionable at best, and kindof a separate issue I suppose.