Description
Is your feature request related to a problem? Please describe.
When debugging and/or logging requests and responses, it can be difficult to access the Request object that was actually used to query the server.
As an example, if you put a link at the top of the Link graph that logs the request and response, and then under that have an AuthLink, you're not able to see the authentication header that was added via the AuthLink. This happens because AuthLink actually creates a copy of the Request with additional information in the Context and passes that down the graph.
Describe the solution you'd like
In the Response object, you would be able to access the final Request object through the context, something like:
final request = response.context.entry<RequestEntry>().request;
This would allow users to access the fully composed Request object (and its context) for logging and debugging issues with complicated Link setups, or whatever else someone may need the request object for.
Describe alternatives you've considered
I'm aware of other methods of snooping the network requests such as the browser or flutter network tools, and I've seen a couple solutions where people create and pass in a custom HttpClient implementation to HttpLink.
The other tools, while effective, aren't as nice for in depth debugging or passive review of events in the case of running into an unexpected error.
As far as a custom HttpClient, requiring a custom HttpClient in order to add in logging or to review the final context of a request/response pair seems antithetical to the cleanliness of Link composition in my opinion. It's quite far down in the stack, and requires separate implementations anywhere a split is involved (such as for WS links vs. HttpLinks).
Having the full request and its context available through the completed response gives you the ability to more consistently handle or inspect the final status of everything from the Link composition pattern, instead of having to inject yourself elsewhere in order to get that access.
Additional context
If this feature is implemented as requested, it may be worth looking into the leaf node Links (like HttpLink and WebSocketLink) and ensure that they're adding useful data, such as headers, to the request's context before actually querying the server so that all relevant information is available in the RequestEntry.