* Move code from RealConnection to RealConnectPlan
Also promote RealConnectPlan to a top-level type, ConnectPlan.
Each RealConnection is now created only once its ready to be used
to carry exchanges. We do the actual connect work in ConnectPlan.
* Move startHttp2() back to RealConnection
* Update FastFallbackExchangeFinder for split RealConnection
* Tests for FastFallbackExchangeFinder
This needed more test facets in TaskFaker.
I'm pretty happy with how the tests read.
* More tests for FastFallbackExchangeFinder.
In order to deterministically test FastFallbackExchangeFinder I need
a test facet that supports several test coordinating:
- the call thread is waiting for either a connection to connect
or for the next-connection timeout (250 ms) to elapse
- the in-flight connection needs to connect
TaskFaker wasn't up to the task for this because it assumed at most
two threads, the test thread and the task thread.
With this change TaskFaker can coordinate multiple task threads
that each run sequentially, as directed by a test thread.
This doesn't yet introduce any mechanism to enable or disable
happy eyeballs.
It also doesn't sort IP addresses to alternate IPv6, IPv4
for best success.
It also doesn't limit how many connections are attempted
simultaneously.
It also lacks an appropriate number of tests.
This is bad because it moves test logic out of tests. But it's also
good because it lowers the cost of writing unit tests with common
types like RealConnection and Route.
I attempted to do a literal translation as much as possible.
Subprojects now need plugins to be configured directly so they
can use the appropriate syntax.
As originally designed DiskLruCache assumes an inode-like
file system, where it's fine to delete files that are
currently being read or written.
On Windows the file system forbids this, so we must be
more careful when deleting and renaming files. These
operations come up a lot internally in the cache:
- deleting to evict an entry
- renaming to commit a dirty file to a clean file
The workaround is simple if unsatisfying: we don't
permit concurrent reads and writes on Windows. We
can have multiple concurrent reders, or a single
writer.
One challenge in this implementation is detecting
whether we're running on Windows or a good operating
system. We deliberately don't look at System properties
here because the OS and file system may disagree, such
as when a Windows machine has an ext4 partition, or when
a Linux machine has an NTFS partition. Instead of detecting
we just attempt an edit and see what happens.
Another challenge in this implementation is what to
do when a file needs to be deleted but cannot be because
it is currently open. In such cases we now mark the
cache entry as a 'zombie'. When the files are later
closed they now check for zombie status and delete the
files if necessary. Note that it is not possible to
store a new cache entry while it is a zombie.
Closes: https://github.com/square/okhttp/issues/5761
