Add OpenTelemetry Tracing capabilities to Cloud Controller

[MarcWoern]

In this change we implement Opentelemetry(OTel) tracing support for the ruby cloud_controller using the official(by OTel community) library opentelemetry-ruby.
It enables the cloud_controller itself to measure traces and spans and send them to a OpenTelemetryProtocol(OTLP) capable backend.

The recorded root span is stored in the with the service-name "cloud_controller_ng-api" or "cloud_controller_ng-worker".
A trace of an api call that starts a delayed_job will cause a link between this api call and the trace of the worker.
The worker inherits the sampling decision of the api call too, meaning a sampled api call will also lead to a sampled job run.
The service name can be used to find the trace in the attached backend. Job samples and Api samples will have a bidirectional link.

When disabled the code that load and initialise the framework as well as the middleware are not used to minimise impact on performance and bug surface.

Instrumentations:
The opentelemetry-ruby library offers a few out of the box instrumentations which extend key function calls in libraries automatically once loaded and measure span.
The used instrumentations and their respective roles include:

• Rack: This middleware instrumentation measures the time spent in the whole Rack application.
• HttpClient: This instrumentation tracks outgoing HTTP requests executed with the httpclient gem.
• HTTP: This instrumentations traces the HTTP client and server-side libraries.
• Mysql2: This instrumentation detects queries, database calls, transactions, etc., made to MySQL using the Mysql2 gem.
• Sinatra: This instrumentation traces the execution of Sinatra applications(used for /v2).
• Redis: This instrumentation traces all commands sent to Redis server using the redis-rb gem.
• Rake: This instrumentation measures the execution time of your Rake tasks.
• CCDelayedJob: This instrumentation traces the enqueue/job execute cycle within delayed jobs. This is a modified version of the DelayedJob instrumentation that propagates trace information so that bidirectional links can be set. It also records some cloud_controller specific job attributes when they are available.
• PG (Postgres): Postgres instrumentation captures SQL queries executed on a Postgres database.
  The instrumentations automatically set spans into traces and spans, which are set manually in the code(OpenTelemetryMiddleware) to track specific activities. Manual spans include:
• middleware-pre-app: This span measures the middleware before the application runs.
• application: This span measures the application runtime(without middleware).

Configuration
To properly configure this functionality following properties will be
introduced:

• [otel][tracing][enabled]: Set this to true or false. If it's false, all functionality regarding OpenTelemetry Tracing is disabled.
• [otel][tracing][api_url]: Set the URL for the API.
• [otel][tracing][api_token]: Set the token for the API
• [otel][tracing][redact][db_statemets]: Set this to true or false. If false the full sql statement will be provided as attribute in the spans of the mysql or pg instrumentation. If set to true, it will log the statements but will redact the query parameters as well as insert/update values by question marks.
• [otel][tracing][sampling_ratio]: Set a float between 0.0 (=0%) and 1.0 (=100%) to define the probability with that traces are sampled.
• [otel][tracing][propagation][accept_sampling_instruction] Set this to true or false. If true, the header passing the sampling value to the cloud_controller will be honoured and make the cloud_controller to also trace. If set to false the tracing information is parsed but it does not influence the sampling decision based on above sampling_ratio.
• [otel][tracing][propagation][extractors]: Here you can set the list of propagators to be extracted. Extractors read the HTTP headers provided and deserialize the contained tracing information.
• [otel][tracing][propagation][injectors]: Here you can set the list of propagators to be injected. Injectors serialize the tracing information into HTTP headers for propagation.

Propagation
Propagation refers to the process of moving tracing data using HTTP headers across service boundaries that can be linked together into a single trace.
Propagators accepted are:

• tracecontext(https://www.w3.org/TR/trace-context/)
• baggage(https://www.w3.org/TR/baggage/)
• b3(https://github.com/openzipkin/b3-propagation)
• b3multi(https://github.com/openzipkin/b3-propagation)
• jaeger(https://www.jaegertracing.io/docs/1.56/client-libraries/#propagation-format)
• xray(https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html#xray-concepts-tracingheader)
• none

Propagators can be differentiated into extractors and injectors. Extractors are responsible for extracting trace context from incoming requests(incoming api calls), while injectors are responsible for injecting trace context into outgoing requests(e.g. to UAA or service brokers).
If more than one injector is configured in the HTTP Request, than the last propagator that can successfully process the supplied headers defines the inherited trace context, in case multiple conflicting trace headers are recieved.
If more than on extractor is configured, the CC will propagate the information in all configured formats.
The propagators tracecontext and jaeger also support baggage. With baggage key-value pairs can be added to the headers. If more than one propagation, which supports baggage, is present, the first baggage key-value pairs are being used.
The propagation functionality hereby replaces the zipkin middleware which was removed, since it implemented the propagation(only, without the cloud_controller adding trace data) for the B3Multi Header exclusively.
The current implementation with OTel can be configured to offer the exact same functionality/behaviour.

• I have reviewed the contributing guide

• I have viewed, signed, and submitted the Contributor License Agreement

• I have made this pull request to the main branch

• I have run all the unit tests using bundle exec rake

• I have run CF Acceptance Tests

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: FloThinksPi / name: Florian Braun (3bbe78b)
• ✅ login: MarcWoern (7d3d56a)

[FloThinksPi]

One gap in testing is the self written delayed jobs tracing instrumentation. It could benefit from some serialisation/deserialisation tests as well as tests to set the links and attributes properly. We did run out of time for that, i think for now this can be reviewed for feedback but before merging we should add tests for the instrumentation.