Add RequestID to http handler and store as a context value

[mkcp]

Feature Description

RequestIDs are a common industry pattern for uniquely identifying a request throughout its lifecycle. In HTTP systems, typically they are generated by the server accepting the initial request and propagated via the header X-Request-ID. I'll call this behavior generate-or-propagate, where you take an ID if it's given or make a new one.

Once we've generated or accepted an X-Request-ID, we can store it as a value on the req.Context to be passed through to whatever endpoint are handles the request.

It's OK for these requestIDs to end at the RPC layer for a first iteration. Down the line we can see about adding generate-or-propagate behavior to RPCs and adding RequestIDs to our RPC structs.

Use Case(s)

This is primarily a debugging-focused feature. RequestIDs give us a mechanism to uniquely identify a request in logged events and more deeply inspect Consul's behavior. The main use case is correlating Consul's logs to a specific HTTP response. Also, if users have instrumentation set up to propagate their own requestIDs, then Consul can participate.

Down the line, when we implement RPC-level propagation, we'd be able to view a set of logs across various multiple Consul processes by selecting the RequestID. The ID can also compose with other debugging features - if we were to store the RequestID in tracing spans we'd be able to correlate a set of traces with the logs of the request(s) involved.

Out of scope

When this issue is completed, we should create an issue for generating-or-propagating RequestIDs through our RPC layer.

[banks]

Down the line we can see about adding generate-or-propagate behavior to RPCs and adding RequestIDs to our RPC structs

Just a quick note to say that our long term plan is to move to gRPC internally instead of msgpackRPC we don't have a tight deadline on that though as it's background work with several dependencies. Depending on timing it may end up being easier if that happens first since gRPC can just use HTTP2 headers to propagate this rather than needing invasive changes to all our structs.