Build the HTTP transport, with timeouts, connection reuse and cancellation

[iderex]

Every other thing the core does goes through one HTTP transport. Built well once,
it is where timeouts, connection reuse and cancellation are decided for the whole
repository. Built badly, every caller writes its own timeout and the core drifts
against itself before a single client exists.

What this produces

One transport type every request goes through. No caller constructs its own.

Separate timeouts for connect, for first byte, and for the whole request, because
a server that accepts a connection and then says nothing is the case a single
overall timeout handles worst and it is the case the slow-server record in #7 is
about.

Connection reuse across requests to one server, since a wall of tiles opens many
requests to the same host and a fresh handshake per tile is a measurable part of
the 1.2 second budget.

Cancellation that actually stops the work, matching what the concurrency record
in #9 promised, so that a tile scrolled off the screen stops costing anything.

Done when

All requests in the repository go through the transport, a test proves each of
the three timeouts independently against the fake server's slow modes, and a
test proves a cancelled request stops rather than completing into a discarded
result. Blocked on #7, #9, #21, and on #102 for the clock each of the three
timeouts is measured against.

[iderex]

The clock this issue was waiting on is decided in docs/decisions/0102-the-clocks-every-deadline-is-measured-against.md.

All three timeouts are on the steady clock. Each of them is an interval between two events inside one run of the core, which is the row the record's table opens with, and a duration is measured on steady or on elapsed and never on the wall clock.

The steady clock rather than the elapsed one, because a device that suspended mid-request has no request left in flight. Counting the sleep against a connect, a first-byte or a whole-request timeout would turn every wake into a timeout, and that is the reason the record gives for the split between the two monotonic clocks.

Two neighbouring intervals are not on this issue's clock and are not decided here. The wait between attempts is retry backoff, on the same steady clock but owned by #38. The age carried by a cached answer is anchored on the server's own stated time rather than on any of the three clocks, and #43 owns it.

The controlled clock the timeout tests need comes from the same record: a test may advance the steady clock by any amount and may never move it backwards, which is what lets each of the three timeouts be proven in microseconds rather than in seconds.

[iderex]

The transport's own decisions landed as docs/decisions/0027-the-transports-timeouts-and-connections.md, on 5246156. The clock they are measured against is settled in the comment above and the record reads it rather than restating it.

Two of the three timeouts this issue asks for are numbers, and the third is not. Two seconds to reach a connection, covering resolution, the machine and the handshake through the point where 0029 decides on the certificate. Two seconds to the first byte of a response. The whole-request timeout is the five seconds 0007 already fixed, and it belongs to the call rather than to the attempt, so an attempt ends on whichever arrives first, its own two seconds or what is left of the caller's five. Writing a third number here would have been a second deadline competing with 0007's.

The per-attempt bounds exist for 0038 rather than for the caller. Three attempts inside one five second deadline is only reachable where a stalled attempt can be ended early, and the record works the arithmetic through so a later change to either number is mechanical: two stalls cost four seconds plus the two waits, so the third attempt starts only where those waits together drew under 500 ms, and then it runs against what is left rather than against the two seconds. The first-byte bound also has a floor it may not cross. At or below 0007's 400 ms it would abandon attempts before late had ever been reported, which makes that state unreachable in the case it was written for.

The connection limit was the part two other records were already resting on. 0007 abandons a request to protect it and gives that as the reason for abandoning at all, and 0009 sizes its waiting lane at one waiter per permitted connection and creates that lane when the core is created. Six to one server and twelve across all of them, which fixes the lane at twelve waiters for the life of the core rather than making it something that grows when a session is added. The count is over requests outstanding against one server whatever number of sockets carries them, which keeps it meaning the same thing if the version turns out to multiplex.

Reuse is decided in the direction that costs nothing and refused in the direction that would. A connection is reused for any session against the same server, because identity travels in the request and the core presents no certificate of its own, so several sessions against one server cost no more connections than one. It is never reused across origins. Five things end one: sixty seconds idle, the server closing it, a response the core did not read to its end, cancellation past the bound below, and the pin for that server changing under 0029, since each connection was accepted under the pin that has just been replaced.

One thing was settled that this issue did not ask for, because 0009 left it open and an unbounded answer would undo what cancellation is for. 0009 says bytes in flight are read and discarded rather than left in the socket, and says why: a connection with unread bytes cannot be reused. How far that reading goes was nowhere. It goes to sixty-four kilobytes or one second, and then the connection is closed instead. Reading on is worth doing only while it is cheaper than the handshake it saves, and past that it spends somebody's link on bytes already discarded. A cancelled tile decides the shape: at up to sixteen megabytes under 0055 an artwork body is far past the bound, so it closes rather than downloading in full to save a handshake.

Two residuals are named in the record rather than solved. Three or more servers active at once contend for the twelve, and a stalled one can hold six of them for as long as 0007's deadline; reserving slots per server would idle most of them on the single-server device, which is nearly every device. And a response that genuinely needs more than five seconds is abandoned, which on a slow link includes a large artwork body. The second has a reversal condition attached, and it supersedes 0007 rather than this record.

The protocol version is not decided here and the record says where it comes from. Redirects are 0069's and were already decided. Which failures are retried is 0038's. The reported states are 0007's. What cancellation promises a caller is 0009's.

All three conditions here are untouched. Every request in the repository going through the transport, a test proving each timeout independently against the fake server's slow modes, and a test proving a cancelled request stops rather than completing into a discarded result are statements about running code, and #21 is open. This stays open on all three.