Fix for keepalivesocketfactory regression

[mariosmeim-db]

This PR introduces the following changes:

• KeepAliveSocketFactory is changed to follow the singleton pattern, and the instance is initialized early
• Changed createURLConnection in BaseRequest to properly get the KeepAliveSocketFactory instance when https keepalive is enabled
• Re-enabled https socket keepalive by default
• Changed the comments in RequestOptions to reflect the changed default value for disableHttpsKeepAlive

One possible issue is thread-safety of the KeepAliveSocketFactory class. Specifically, do you think we should take further steps to ensure that the createSocket methods are thread safe? Any other concerns?

[msftclas]

All CLA requirements met.

[rickle-msft]

@mariosmeim-db Thank you for submitting this! We appreciate the contribution.

I'll actually ask you to keep the default unchanged just in case there are other unforseen behavior changes. I know you guys have done testing, but it's actually the policy of my team to not change the default with these sorts of things to preserve behavior for existing customers. When I changed the default in 8.6.1, that was my mistake.

I don't have any concerns about thread-safety, though it is a good question. There's no state held in our wrapper implementation of the factory, so there's not really an opportunity for threads to corrupt the state of the factory. I think the underlying implementation will have taken any necessary precautions for thread-safety as this type was probably designed to be used in this way (setting it on a connection). And the only state we are changing, we always set to true, so even if threads do interfere with each other (which I again don't think is possible as all the logic is local to the method), they'll all be setting the same value anyways. Is there something else I missed that you might be concerned about?

Please note that you need to sign the CLA before this can be merged.