Update Graphana Tempo config for latest version (#10055)

## What changed?

Updates the Graphana Tempo configuration used for the service when
running locally. (Simply copying a more recent version of the
single-binary setup.)

Fixes #10053.

## Why?

Previously, the Tempo container would fail on startup. Preventing any
collection of OTel traces. It appeared to stem from breaking changes in
the Tempo service itself, as it modified the schema of its configuration
file.

I'll admit I am out of my depth here. But some of the field changes are
called out in their upgrade guide here:

https://grafana.com/docs/tempo/latest/set-up-for-tracing/setup-tempo/upgrade/

## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] ~covered by existing tests~ - NA?
- [ ] ~added new unit test(s)~ - NA?
- [ ] ~added new functional test(s)~ - NA?

I ran the
https://github.com/temporalio/samples-go/tree/main/opentelemetry sample,
and within the Graphana UI on http://localhost:3000/ I saw data showing
up.

<img width="1244" height="620" alt="image"
src="https://github.com/user-attachments/assets/320642a8-1b91-4428-bb6d-1f2b090016b8"
/>

Author: chrsmith

develop/docker-compose/grafana/provisioning/tempo/tempo.yaml

@@ -1,55 +1,18 @@
-# Copied from https://github.com/grafana/tempo/blob/main/example/docker-compose/local/tempo.yaml
-
+# Copied from https://github.com/grafana/tempo/blob/main/example/docker-compose/single-binary/tempo.yaml
 stream_over_http_enabled: true
+
 server:
   http_listen_port: 3200
   log_level: info
 
-cache:
-  background:
-    writeback_goroutines: 5
-  caches:
-    - roles:
-        - frontend-search
-      memcached:
-        host: memcached:11211
-
-query_frontend:
-  search:
-    duration_slo: 5s
-    throughput_bytes_slo: 1.073741824e+09
-    metadata_slo:
-      duration_slo: 5s
-      throughput_bytes_slo: 1.073741824e+09
-  trace_by_id:
-    duration_slo: 100ms
-  metrics:
-    max_duration: 120h # maximum duration of a metrics query, increase for local setups
-    query_backend_after: 5m
-    duration_slo: 5s
-    throughput_bytes_slo: 1.073741824e+09
-
 distributor:
-  receivers: # this configuration will listen on all ports and protocols that tempo is capable of.
-    jaeger: # the receives all come from the OpenTelemetry collector.  more configuration information can
-      protocols: # be found there: https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver
-        thrift_http: #
-        grpc: # for a production deployment you should only enable the receivers you need!
-        thrift_binary:
-        thrift_compact:
-    zipkin:
+  receivers:
     otlp:
       protocols:
-        http:
         grpc:
-    opencensus:
-
-ingester:
-  max_block_duration: 5m # cut the headblock when this much time passes. this is being set for demo purposes and should probably be left alone normally
-
-compactor:
-  compaction:
-    block_retention: 24h # overall Tempo trace retention. set for demo purposes
+          endpoint: "tempo:4317"
+        http:
+          endpoint: "tempo:4318"
 
 metrics_generator:
   registry:
@@ -61,16 +24,14 @@ metrics_generator:
     remote_write:
       - url: http://prometheus:9090/api/v1/write
         send_exemplars: true
-  traces_storage:
-    path: /var/tempo/generator/traces
-  processor:
-    local_blocks:
-      filter_server_spans: false
-      flush_to_storage: true
+
+query_frontend:
+  mcp_server:
+    enabled: true
 
 storage:
   trace:
-    backend: local # backend configuration to use
+    backend: local
     wal:
       path: /var/tempo/wal # where to store the wal locally
     local:
@@ -79,5 +40,9 @@ storage:
 overrides:
   defaults:
     metrics_generator:
-      processors: [service-graphs, span-metrics, local-blocks] # enables metrics generator
+      processors: ["span-metrics", "service-graphs"]
       generate_native_histograms: both
+
+
+usage_report:
+  reporting_enabled: false