* OkHttpClientTestRule check connectionCount instead of idle
Clients should be clean after use, not just from idle connections.
* Abandon unclean clients
* Simplify logic
I'm hoping to follow this up with a change so that this rule can also do the
uncaught exception handling that we're currently doing elsewhere.
See https://github.com/square/okhttp/issues/4894
When connections are established concurrently, verify() sometimes throws a `java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0` because of unsynchronized access to the `calls` list.
This will help prevent regressions and point to the leaking test, rather than to a later test that happens to checks for leaks. The change is applied to all tests that have an OkHttpClient member variable.
There's a big consequence to this for compatible with RFC 2965 Cookies. In particular,
this drops our ability to support 'Set-Cookie2' headers, and some features used there
including quoted attributes like 'Max-Age="25"'. This is the right move for interop with
browsers, and likely to make things better for application developers, but some
people who strictly followed the RFC 2965 spec will be broken. (That spec was never
seriously adopted anywhere, which is the entire motivation of RFC 6265.)
The upside is the CookieJar interface is now much more straightforward. This is
particularly good going forward, and for clients who don't have to worry about the
strangeness of things like $Version=1 in the RFC 2965 spec.
We aren't yet ready to make FileSystem a public type, but I don't mind
making it _almost_ available via an internal API for those brave enough
to try that.
Also migrate all of our tests to use the in memory file system. It's simpler.
https://github.com/square/okhttp/issues/1459
I contemplated supporting them in HttpUrl, but then realized I'd
either need to document that behavior (which is weird behavior)
or return ws from the scheme (which seems arbitrary.)
Doing it in Request seems less bad: we support websockets requests.
