Refactor the built-in Samplers for probability sampling #2179
Description
What are you trying to achieve?
For the probability sampling specification, a review comment in #2047 points to a potential for inconsistency stemming from the ParentBased Sampler API, which permits configuring different samplers based on the parent context's sampled flag.
The comment #2047 (comment) thread points out that ParentBased which is configured with up to 5 Samplers can be replaced by two primitives, DelegatingSampler (configured with up to 3 Samplers) and FlagSampler (with zero parameters, only used for non-roots).
What would we like to see?
As we introduce probability sampling and wish to avoid inconsistencies resulting from improper Sampler configuration, the ideal state seems to be the following set of built-in samplers:
ConsistentParentProbabilitySampler (0 parameters) that validates the OpenTelemetry tracestate fields in #2047 and otherwise does what the hypothetical FlagSampler described above would do.
ConsistentProbabilitySampler (1 parameter: probability) that implements the sampling logic in #2047 and records OpenTelemetry tracestate
DelegatingSampler (1 required parameter: root Sampler, 2 optional parameters: localParent, remoteParent Samplers): implements the former ParentBased style of delegation and enforces consistent adjusted counts when delegating for non-root spans
with two built-in aliases:
AlwaysOn (0 parameters) equivalent to ConsistentProbabilitySampler(1)
AlwaysOff (0 parameters) equivalent to ConsistentProbabilitySampler(0)