Document Context keys

[Geal]

the request context is used a lot to carry data between parts of the router, there should be a central place in documentation to list them.

Rough list for now:

• apollo_authentication::JWT::claims: claims extracted from a JWT if present in the request
• apollo_authorization::authenticated::required: true if the query covers type of fields marked with @authenticated
• apollo_authorization::scopes::required: if the query covers type of fields marked with @requiresScopes, it contains the list of scopes used by those directive applications
• apollo_authorization::policies::required: if the query covers type of fields marked with @policy, it contains a map of policy name -> Option<bool>. A coprocessor or rhai script can edit this map to mark true on authorization policies that succeed or false on ones that fail
• experimental::expose_query_plan.plan: contains the query plan serialized as JSON (editing it has no effect on execution)
• experimental::expose_query_plan.formatted_plan: query plan formatted as text
• apollo_override::unresolved_labels: used in progressive override, contains the list of unresolved labels
• apollo_override::labels_to_override: used in progressive override, list of labels for which we need an override
• apollo_telemetry::client_name: client name extracted from the client name header
• apollo_telemetry::client_version: client version extracted from the client version header
• apollo_operation_id: contains the usage reporting stats report key
• persisted_query_register: true if the request registered a query in APQ
• persisted_query_hit: present if the request used APQ, true if we got a cache hit for the query id, false otherwise
• operation_name: name of the operation (according to the query and the operation_name field in the request)
• operation_kind: can be Query, Mutation or Subscription

[bnjjj]

Before documenting it, I suggest a small refactor to keep consistencies between them for router 2.0. cc @garypen for router 2.0 that could also be a task