feat: (qe) Telemetry capturing for PDP/Data proxy

[miguelff]

Extracted from #3505 and to be released after the preparatory refactoring in #3617

Tracked in https://github.com/prisma/client-planning/issues/158
Sibling to prisma/prisma#16748
Closes https://github.com/prisma/client-planning/issues/138
Closes https://github.com/prisma/client-planning/issues/144
Closes https://github.com/prisma/client-planning/issues/145

Implements traces and log capturing in concordance with the (private link) contract specification

The technical design is best explained throw the interaction diagram below:

In the diagram, you will see objects whose lifetime is static. The boxes for those have a double
width margin. These are:

• The server itself
• The global TRACER, which handles log! and span! and uses the global PROCESSOR to
  process the data constituting a trace Spans and log Events
• The global PROCESSOR, which manages the Storage set of data structures, holding logs,
  traces (and capture settings) per request.

Then, through the request lifecycle, different objects are created and dropped:

• When a request comes in, its headers are processed and a [Settings] object is built, this
  object determines, for the request, how logging and tracing are going to be captured: if only
  traces, logs, or both, and which log levels are going to be captured.
• Based on the settings, a new Capturer is created; a capturer is nothing but an exporter
  wrapped to start capturing / fetch the captures for this particular request.

Then the capturing process works in this way:

• The server receives a query [1]
• It grabs the HTTP headers and builds a Capture object [2], which is configured with the settings
  denoted by the X-capture-telemetry
• Now the server tells the Capturer to start capturing all the logs and traces occurring on
  the request [3] (denoted by a trace_id) The trace_id is either carried on the traceparent
  header or implicitly created on the first span of the request. To start capturing implies
  creating for the trace_id in two different data structures: logs and traces; and storing
  the settings for selecting the Spans and Event to capture [4].
• The server dispatches the request and Somewhere else in the code, it is processed [5].
• There the code logs events and emits traces asynchronously, as part of the processing [6]
• Traces and Logs arrive at the TRACER, and get hydrated in the PROCESSOR [7],
  which writes them in the shard corresponding to the current trace_id, into the
  logs and traces storage [8]. The settings previously stored under the trace_id
  key, are used to pick which events and spans are going to be captured based on their level.
• When the code that dispatches the request is done it returns a PrismaResponse to the
  server [9].
• Then the server asks the PROCESSOR to fetch the captures [10]
• And right after that, it fetches the captures from the Storage [11]. At that time, although
  that's not represented in the diagram, the captures are deleted from the storage, thus
  freeing any memory used for capturing during the request
• Finally, the server sets the logs and traces extensions in the PrismaResponse[12],
  it serializes the extended response in json format and returns it as an HTTP Response
  blob [13].

[tomhoule]

With all the context and future plans we discussed, let's merge this.

[miguelff]

80442d5 fixed the problem with BEGIN statements not being captured at the beginning of the request.

curl -X POST http://localhost:57581/transactions/start -H 'Content-Type: application/json' -H 'X-capture-telemetry: query,tracing' -d '{"max_wait":2000,"timeout":5000}'

{
  "id": "cldensyuh0002rb9nzo10w4iy",
  "extensions": {
    "logs": [
      {
        "span_id": "563b074839c5c57e",
        "level": "query",
        "timestamp": [
          1674832125,
          565891000
        ],
        "attributes": {
          "params": "[]",
          "query": "SELECT 1",
          "duration_ms": "12"
        }
      },
      {
        "span_id": "3b3817ccec15d3e9",
        "level": "query",
        "timestamp": [
          1674832125,
          572383000
        ],
        "attributes": {
          "query": "BEGIN",
          "duration_ms": "4",
          "params": "[]"
        }
      }
    ],
    "traces": [
      {
        "trace_id": "73797568303030327a6f313077346979",
        "span_id": "563b074839c5c57e",
        "parent_span_id": "fc6e12b498c57dce",
        "name": "prisma:engine:db_query",
        "start_time": [
          1674832125,
          553089000
        ],
        "end_time": [
          1674832125,
          566096000
        ],
        "attributes": {
          "db.statement": "SELECT 1"
        }
      },
      {
        "trace_id": "73797568303030327a6f313077346979",
        "span_id": "fc6e12b498c57dce",
        "parent_span_id": "6925d3c29b00efb1",
        "name": "prisma:engine:connection",
        "start_time": [
          1674832125,
          552560000
        ],
        "end_time": [
          1674832125,
          567526000
        ],
        "attributes": {
          "db.type": "postgres"
        }
      },
      {
        "trace_id": "73797568303030327a6f313077346979",
        "span_id": "3b3817ccec15d3e9",
        "parent_span_id": "6925d3c29b00efb1",
        "name": "prisma:engine:db_query",
        "start_time": [
          1674832125,
          567792000
        ],
        "end_time": [
          1674832125,
          572568000
        ],
        "attributes": {
          "db.statement": "BEGIN"
        }
      }
    ]
  }
}