Add experimental composite sampler

[anuraaga]

This is a reopening of open-telemetry/opentelemetry-python-contrib#3668 as was recommended to target this repo.

Looking at some other similar _ exports for experimental features, they seem to be complete concepts (i.e. logs), while this is a type of an existing concept, sampler. So I tried the _sampling_experimental name to clarify that it is an experimental part of sampling. Let me know any thoughts.

Description

Adds an implementation of consistent samplers

https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling/
https://opentelemetry.io/docs/specs/otel/trace/sdk/#built-in-composablesamplers

Based on the Java implementation

https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/consistent-sampling/src/main/java/io/opentelemetry/contrib/sampler/consistent56

Some differences from Java

• Names follow the published experimental spec rather than OTEP
• Does not add non-standard samplers for now, e.g. ratelimited, rule based
• Some trace state validation is assumed to be done by the SDK and invalid cases aren't tested (the API doesn't accept string but SDK TraceState)

/cc @xrmx @tammy-baylis-swi
/cc @PeterF778 as original author in Java if interested

Type of change

• New feature (non-breaking change which adds functionality
• This change requires a documentation update

How Has This Been Tested?

• Unit tests

Does This PR Require a Core Repo Change?

• No.

Checklist:

See contributing.md for styleguide, changelog guidelines, and more.

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[xrmx]

Added a bunch of comments, I have yet to review the PR after looking at the doc here
https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling/

[anuraaga]

Thanks all. Actually I had realized while I was looking at the tracestate handling section of the spec, I completely missed the SDK portions... So I have compared with that and renamed things to match it. Notably, the word consistent isn't used much and the concept seems to composite sampling.

One note is I made an editorial decision on the public API - one thing I noticed with the sampling.py one is some samplers are constants, others are classes, which seemed inconsistent. Here I hid all the classes and only expose functions to be able to use singleton or not as needed with a consistent surface. Happy to go with anything the maintainers prefer though.

[tammy-baylis-swi]

Thanks @anuraaga for the revisions and renames. Please could you do a tox -e ruff and commit the formatting fixes so the precommit passes.

[anuraaga]

Thanks @tammy-baylis-swi sorry for missing that - ran formatting