fix: traces success response to be Ok instead of Accepted

[shreyamalpani]

What does this PR do?

• Updates the trace success response to report a 200 Ok status code instead of 202 Accepted status code
• Returns a "rate_by_service" map to satisfy this requirement by the tracer.

Motivation

Excessive warn logs reported by customer

Additional Notes

The Java Tracer was sending warn logs because it expects a response status code of 200 on success:

{"message":"Successfully buffered traces to be flushed."} while sending 1 (size=2KB) traces. Total: 22, Received: 22, Sent: 0, Failed: 22. Status: 202 Accepted (Will not log warnings for 5 minutes)

After updating the status code, the Java tracer was sending an error since the success response body contains a message attribute instead of rate_by_service:

[dd.trace 2025-01-17 22:48:37:287 +0000] [dd-trace-processor] ERROR datadog.trace.agent.common.writer.TraceProcessingWorker$DaemonTraceSerializingHandler - Uncaught exception com.squareup.moshi.JsonDataException: Expected BEGIN_OBJECT but was STRING at path $.message in dd-trace-processor

Changing the response body to {"rate_by_service":{"service:,env:":1} fixed this error.

• This sets a default per-service sampling rate, which should not impact Lambda as ddtrace is already treating lambda as its own service

A similar issue was encountered earlier with Azure Spring Apps - DataDog/libdatadog#547