okhttp: support Conscrypt security provider

[ericgribkoff]

This addresses #3966 and incorporates the text changes to SECURITY.md from #3301. Tested with org.conscrypt:conscrypt-android:1.0.0.RC14, as well as Google Play's security provider.

This changes our detection of the Google Play security provider from using the class name to the provider name, GmsCore_OpenSSL. This would seem to be equally as stable, and recent versions of OkHttp do the check similarly, although I realized in testing this that OkHttp uses GMSCore_OpenSSL, which did not work in my tests (checking elsewhere, it should indeed be GmsCore_OpenSSL, and the lookup is case-sensitive).

[ejona86]

try-finally or similar (could maybe remove it unconditionally in the @After).

[ejona86]

We should prefer insertProviderAt so that Conscrypt can be prioritized.

[ericgribkoff]

Done

[ejona86]

We should loop through the providers in order and choose the first we can use. That way the user has some way of configuring our behavior, and our behavior will better match expectations.

[ericgribkoff]

Done

[ericgribkoff]

Moved the logic to decide what TLS extensions are available into Platform. This seems like where it belongs, since the Platform already decides on the security provider using similar logic. This means that tests of this logic are gone from OkHttpProtocolNegotiatorTest (but this maybe isn't so much worse than the status quo since we never had tests for picking the actual provider anyways). I've manually tested the changes on emulators, but this almost certainly deserves some test coverage. I didn't add tests yet, as to-date we don't have any (?) tests of the copied OkHttp classes (and simulating all the different platforms/API levels looks a little tricky), but I can add tests if the approach here looks good.

Worth noting: recent Android builds have AndroidNSSP (Android Network Security Policy) as the #1 security provider. I haven't looked into it, but it might be worthwhile adding this to the list of recognized security providers later.

[ericgribkoff]

@ejona86 FYI this was heavily refactored/redone since the earlier approval, so I'm holding off on merging until you have a chance to (re)review