Replace the use of TCP in the test suite with Twisted's
StringTransport, specifically StringTransportWithDisconnection which
allows us to trigger a disconnect event on the server side during testing.
The `dataReceived` method on the server is now called directly, and any
effects will be realised immediately.
Responses are available to the test client using the `value()` method of
the transport objects, and the buffer can be cleared using `clear()`.
This allows all asynchronous behaviour to be removed from the transit
server test suite.
Furthermore, as we never have to wait for the server, tests no longer
hang if they fail: the errors are encountered immediately.
If the client connected and then immediately disconnected, or disconnected
before sending enough of a handshake to be classified as good or bad, we
tried to record the usage record as if the connection was complete ("happy"),
which triggered an assertion. This dumps an error to the log and failed to
record the usage record. In May 2020, this happened 55 times in 40 days.
If the file receiver hangs up on an established connection, we do a
`transport.loseConnection()` on the buddy (the file sender). But apparently
it takes a moment (perhaps a roundtrip through the kernel) for the incoming
data to stop, and that used to cause an error. In May 2020 this happened 11
times in 40 days. Now we just ignore this late data.
The default was "tcp:4001", which happens to expand into
"tcp:4001:interface=127.0.0.1", which limits the listening socket to IPv4
connections only.
Changing it to "tcp:4001:interface=\:\:1" means "listen on ::1", which is the
IPv6 name for the loopback interface, and gets us a socket that accepts both
IPv4 and IPv6 connections.
Note: this might cause incompatibilities with IPv4-only hosts, if they don't
accept the "::1" name. For these systems, run the server as `twist
transitrelay --port=tcp:4001" to revert to the old behavior.
closes#12
