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
Maybe windows+py36 was failing because "456" is too small of a value, and the
OS time libraries can't figure out UTC for something back in 1970. Switch to
a fixed timestamp from just a few minutes ago, to see if it likes 2018
better.
For some reason, the appveyor (windows) tests fail on py36 with an OSError
during an internal (twisted.python.log) call to datetime.fromtimestamp().
It's possible that my mock times are too old (I'm using made-up values like
"456"), but maybe it's just that real time.time() returns a float instead of
an integer.
