RemoteGraphQLDataSource request lifecycle hooks not working as expected for APQ

Extract from [documentation](https://www.apollographql.com/docs/federation/api/apollo-gateway/):

> class RemoteGraphQLDataSource
>
> Represents a connection between your federated gateway and one of your implementing services.
>
> You can customize this connection by extending this class and overriding its willSendRequest and/or didReceiveResponse methods:
>
> Override willSendRequest to modify your gateway's requests to the implementing service before they're sent.
>
> Override didReceiveResponse to modify the implementing service's responses before the gateway passes them along to the requesting client.

#### Package

@apollo/gateway 0.19.1

#### Expected behavior

- willSendRequest is invoked before each request sent to implementing service.
- request.extensions matches the data that will be sent.
- didReceiveResponse is invoked after each response received from implementing service.

#### Actual behavior

When APQ is enabled the persisted query extension data is added after willSendRequest is invoked, so is missing at this point.

When APQ is enabled and the optimistic request fails, two separate HTTP requests are sent to the implementing service, but the willSendRequest and didReceiveResponse hooks are only invoked once.

#### Possible solution

I understand that the current willSendRequest and didReceiveResponse hooks make sense for most scenarios where it only matters what general GraphQL request data will be sent and what is received. But for cases where the actual physical HTTP requests being sent over the wire are important then there should be hooks within the RemoteGraphQLDataSource.sendRequest function that are called before and after **EVERY** HTTP request.

Start with RemoteGraphQLDataSource.sendRequest in the @apollo/gateway implementation and trace the APQ optimistic-request retry flow. Compare the documented willSendRequest and didReceiveResponse behavior with each physical HTTP request. Done means persisted-query extensions are present when the request hook runs and both hooks run for every request and response.

Written by the indexing model from the issue text.