Apply fix for devices with large socket buffers

The same fix as for ThreadInterruptTest from commit
d95341bb7bc13ee2a4c7a08d6c7f9944a8a51ae3, but made to
DisconnectTest.
bind specifically to a loopback interface
Update to h2-16, hpack-10.
Merge pull request #1202 from adriancole/adrian.h2-16

Update to h2-16, hpack-10
Merge pull request #1197 from nfuller/FixDisconnectTest

Apply fix for devices with large socket buffers
Track exception message changes for the dynamic table.
Merge pull request #1194 from mruddy/loopback

mockwebserver: bind specifically to a loopback interface
Merge pull request #1204 from square/jwilson_1215_exception_message

Track exception message changes for the dynamic table.
Update to Okio 1.1.0.
Merge pull request #1205 from square/jw/one-one-oh

Update to Okio 1.1.0.
Modify the cipher suite / TLS version selection behavior

Work in progress. Sent for consideration.

Motivation 1: Opinionated cipher suite selection makes sense for
OkHttp when bundled with apps. OkHttp probably has the best/newest
information available when compared with the socket factory it
encounters.

However, with the Android platform usecase the socket factory (the
one from the platform, from GMS core or installed by the app) might
have better information (or reasons why specific suites should not be
used and so modifies the enabled set). Android would therefore prefer
OkHttp to use the default set.

Motivation 2: TLS protocol version selection is performed over
"supported" not "enabled" values. This will cause protocols that are
disabled by default to be re-enabled. Similar argument here as for
motivation 1: Android would like to avoid enabling protocols that
are considered unsafe and are disabled by the apps or GMS core.

----

This change includes the ability to select from "enabled" or
"supported" values for both sets, and introduces the ability to use
the default set of ciphers.

This change is probably overkill depending on whether you believe
that the supported Vs enabled behavior is a bug or a feature. With
this change Android can specify what it wants while retaining
existing OkHttp behavior. I am looking for guidance on what subset
you would be happy with.

When I understand what we want I can add a ConnectionSpec test.

The ConnectionSpec caching has been removed from ConnectionSpec.
This seems like an risky optimization to me in an environment where
different SocketFactory instances could be encountered and doing it
properly seems costly and of limited benefit.

In a later change I am also going to want to repeat an Android
change where we will not attempt a fallback connection if we know
it will not be valid (e.g. if none of the TLS versions or cipher
suites would be supported / enabled). It may make sense to postpone
the TLS version change until that is discussed. The decision about
whether a fallback can be attempted has to be made on the prior
connect attempt and so requires more extensive changes that may
modify the ConnectionSpec API.