Port WebResource keepAlive setting from 2.x to 1.x

[joshgummersall]

This port will allow the Bot Framework SDK to better support customer bots with high traffic.

For some more context, the Bot Framework JS SDK currently makes heavy use of the @azure/ms-rest-js library. Due to requirements around backwards compatibility, we are tied to the 1.x branch (currently v1.8.15). In particular, we support customization of the underlying Axios HTTP client. In effect, this means that upgrading to the 2.x version of this library is currently not tenable.

In order to better support customers with high traffic bots running on Azure, we need to leverage HTTP keepalive as much as possible. The 2.x version of this library added a keepAlive setting to the WebResource class (though, to be fair, exposing an agent parameter directly might be even more friendly). This PR ports this functionality back to the 1.x branch and uses a shared pair of http/https agents so that HTTP connections can be shared across instances of the HTTP client (similar to the shared axios instance).

With this change, the Bot Framework SDK can support enabling keepAlive using a request policy:

import { HttpOperationResponse, RequestPolicy, ServiceClientOptions, WebResource } from '@azure/ms-rest-js';

const options: ServiceClientOptions = {};

const create = (nextPolicy: RequestPolicy): RequestPolicy => {
    const sendRequest = (httpRequest: WebResource): Promise<HttpOperationResponse> => {
        httpRequest.keepAlive = true;
        return nextPolicy.sendRequest(httpRequest);
    };

    return { sendRequest };
};

options.requestPolicyFactories = (factories) => [...factories, { create }];

Here is a sample issue on the Bot Framework SDK repo that illustrates that this is a pain point for current users.

I'm happy to put in more legwork here if this change seems reasonable.

Moreover, if supporting a ServiceClientOptions.agentSettings option seems reasonable I am happy to work on that on both the 2.x and 1.x branches. I think this could be a really useful feature because it would allow users of the library to have complete control over the HTTP(S) Agent used for outbound requests. In fact, I was 85% done writing that code on the 1.x branch before I realized I ought to mimic the behavior added to the 2.x release first.

[stevengum]

This change will help a lot of customers, thanks for creating the PR!

Moreover, if supporting a ServiceClientOptions.agentSettings option seems reasonable I am happy to work on that on both the 2.x and 1.x branches. I think this could be a really useful feature because it would allow users of the library to have complete control over the HTTP(S) Agent used for outbound requests.

I agree that surfacing a way for users to configure the Agent or provide their own Agent would be amazing. Users providing their own Agent would also lower the surface area of @azure/ms-rest-js because it no longer needs to manually plumb through proxy configurations and keepAlive values.

[carlosscastro]

This change would be incredibly impactful to improve the development experience of Bot Framework SDK developers!!!

[daviwil]

Looks good! The CI error is related to some old checks used in this repo, unrelated to this change. I'll ship the update once CI on master completes.

[joshgummersall]

Awesome, thanks for the quick review & merge @daviwil!

[daviwil]

Strangely the CI automation is failing on 1.x branch, might be tomorrow before the update goes out if I have to fix anything. I'll keep you posted here.

[joshgummersall]

Sounds good, thanks.

[EricDahlvang]

This is great! thanks @joshgummersall