Add configuration and features to logging

[bnjjj]

close #1998

Basic configuration

By default some logs containing sensible data (like request body, response body, headers) are not displayed even if we set the right log level.
For example if you need to display raw responses from one of your subgraph it won't be displayed by default. To enable them you have to configure it thanks to the when_header setting in the new section experimental_logging. It let's you set different headers to enable more logs (request/response headers/body for supergraph and subgraphs) when the request contains these headers with corresponding values/regex.
Here is an example how you can configure it:

telemetry:
  experimental_logging:
    format: json # By default it's "pretty" if you are in an interactive shell session
    display_filename: true # Display filename where the log is coming from. Default: true
    display_line_number: false # Display line number in the file where the log is coming from. Default: true
    # If one of these headers matches we will log supergraph and subgraphs requests/responses
    when_header:
      - name: apollo-router-log-request
        value: my_client
        headers: true # default: false
        body: true # default: false
      # log request for all requests coming from Iphones
      - name: user-agent
        match: ^Mozilla/5.0 (iPhone*
        headers: true

/!\ This PR also upgrade tracing (not to the latest version) because I needed a fix.

TODO:

• Add tests
• Configure it with dev mode

[BrynCooke]

Couple of high level observations:

• It would be nice to not have separate log events for subgraph request and response attributes. It feels like this should be one event for request and one for response.
• I would expect that events should be at info. Debug events shouldn't need config in our yaml and can already be controlled via RUST_LOG or APOLLO_LOG. What'll happen is that users will configure this but the events won't make it to their APM unless they also set their log level to debug.

[garypen]

A lot of this looks great. I've got one extra question: What does the performance data look like for this change? And, not related to this change, but something I think about now and then, does our perf testing actually do any logging?

[bnjjj]

@gary We have logs enabled in our performance test. So after launching this on performance test it has no impact on the performance. BUT... the logging configuration is not set at all. One thing to keep in mind and also that was the main reason for me to write a tracing Layer is for example when it enters in the enabled method it will be called only one time for each callsite, it means only one time for each log tracing::info/debug/... in our code. If this method returns false it won't go back again in this method because this callsite has been disabled so it won't do the process again and again for each call. It's a little bit different for the on_event_enabled method because in this method we're looking at the value of the subgraph attribute.

[bnjjj]

New configuration suggestion:

# Log every request, but this is never on by default.
logging:
  requests: true

# Explicitly on in --dev, documented as such.
# Also possible to just set it and have it on in production
logging:
  requests:
     with_header_present: apollo-router-log-request

## MAYBE

logging:
  requests:
     when_header_present: apollo-router-log-request
     request_headers: true
     request_body: true
     request_body: true

[bnjjj]

New suggestion #1998 (comment)

[garypen]

Approving, but I'd like to understand if there's a change in behaviour before merging.