Better handling of invalid (zero) trace and span IDs

[fiadliel]

A trace or span ID with a value of zero (all bits set to zero) are generally considered invalid. In addition to being a general OpenTelemetry requirement, it is also an attribute of the W3C trace context specification (trace and span IDs with a value of zero should not be allowed).

Currently, this restriction is not enforced within Fastrace.

There are a few levels of change which can improve the support.

Minimally, add a TraceId::is_invalid, TraceId::Invalid, SpanId::is_invalid and SpanId::Invalid so that implementers of extensions don't need to peek into .0 to decide whether or not they can handle this particular trace or span. Modify trace context parsing to deny any incoming traces with these values.

A larger change would be to make the underlying implementations for IDs NonZeroU64 and so forth, and update the API accordingly, but this would probably require a few changes to the core API (e.g. Default doesn't make so much sense for TraceId and SpanId).

I'm happy to do a PR if you'd like help with this, but would like to know first what level of changes you're willing to accept here.

[andylokandy]

Thank you for raising this discussion!

You are absolutely correct that the W3C standard prohibits all-zero trace IDs and span IDs. I agree that enforcing or warning against such invalid values is best handled either at the input stage (where Traceparent is generated) or by the consuming systems (e.g., Datadog/Jaeger). As an intermediate library, Fastrace should respect and propagate upstream inputs as-is.
In my opinion, it seems reasonable to output trace IDs and span IDs exactly as the user provided them, ensuring consistency with their expectations.

To further improve correctness, we could consider removing APIs (like Span::default()) that might inadvertently generate invalid IDs. This would help prevent potential misuse and align better with the W3C standard.

[andylokandy]

I'm going to remove Default implementation for SpanId and TraceId, but it'll introduce a breaking change so I'll make the change on 0.8.0.