ref(spans): Run process-segments as a task in devenv

[untitaker]

Segments are already processed by the process_segment task in production.
This flips the default of spans.buffer.process-segments-task-rollout-rate to
1.0 and drops the dedicated process-segments Kafka consumer from devservices
and the devserver, so devenv matches production.

The flusher spawns the task directly, so no raw-mode taskbroker topic is
involved.

Self-hosted counterpart: getsentry/self-hosted#4488

ref STREAM-1568

[linear-code]

STREAM-1568

[sentry]

Bug: If apply_async_with_future returns None, span segments are silently dropped because there is no fallback to the Kafka-based processing path.
_{Severity: MEDIUM}

Suggested Fix

When task_produce_future is None after calling apply_async_with_future, either log an error to make the failure visible or implement a fallback to the Kafka-based produce call. This ensures segments are not silently lost when the task cannot be queued.

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/options/defaults.py#L3308

Potential issue: In `src/sentry/spans/consumers/process/flusher.py`, when processing
span segments, the code attempts to use a task-based approach if the
`spans.buffer.process-segments-task-rollout-rate` option is enabled. If the call to
`apply_async_with_future` returns `None`, the corresponding segment is silently dropped.
There is no fallback to the Kafka-based processing mechanism and no error is logged,
leading to silent data loss. This change makes the task-based approach the default in
development environments, increasing the risk of this issue occurring if the task broker
is misconfigured or unavailable.

Also affects:

• devservices/config.yml:157~162
• src/sentry/runner/commands/devserver.py:336~336

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