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.
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.
This code was originally in magic-wormhole, embedded in the server startup
code. I carved it out to a separate file (with tests) in mailbox-server, but
it should be used here too.
These files are copied (with roughly-appropriate changes to the top-level
setup.py, NEWS.md, etc) from magic-wormhole 0.10.3, commit
be166b483c5796ab3a9ad588ccf671b7eabdd96c).
