feat(dynamic-sampling): add is_segment filter for span metrics in boost_low_volume_projects

[shellmayr]

Add support for querying span metrics in boost_low_volume_projects by:

• Introduces new measure SEGMENTS in addition to SPANS and TRANSACTIONS. This is done primarily to differentiate between spans and segments - spans should continue to be used for the queries for DS on AM3
• Using dynamic use_case_id (SPANS vs TRANSACTIONS) based on the measure

Closes TET-1679

[linear]

TET-1679 Use segment count per root in BoostLowVolumeProjects

[sentry]

Bug: The new SamplingMeasure.SEGMENTS enum is defined and configured, but no production code path can ever select it, rendering the feature non-functional.
_{Severity: MEDIUM}

Suggested Fix

Modify the partition_by_measure() function to correctly return SamplingMeasure.SEGMENTS for organizations that should be using this measure. This likely involves adding a new option, such as "dynamic-sampling.measure.segments", and checking for it within the function to route organizations to the new SEGMENTS logic.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: src/sentry/dynamic_sampling/types.py#L27

Potential issue: The code introduces a new `SamplingMeasure.SEGMENTS` enum member and
its configuration in `MEASURE_CONFIGS` to allow counting spans with the
`is_segment=true` tag. However, the `partition_by_measure()` function, which determines
the sampling measure for an organization, is never updated to return
`SamplingMeasure.SEGMENTS`. It only checks for the `"dynamic-sampling.measure.spans"`
option and returns `SamplingMeasure.SPANS`. As a result, the new logic for counting
segments is never executed in production, and the system will continue to count all
spans instead of just segments. This makes the feature incomplete and non-functional.

_{Did we get this right? 👍 / 👎 to inform future reviews.}