Potential bugs in dc tests

[maddeleine]

Problem:

We seem to be ignoring when the server.accept() returns None in our dc.rs tests. I don't know if that was intentional, but it feels like it probably wasn't, because we don't do anything if server.accept() returns None. All of our result parsing occurs only if server.accept() returns Some(Connection). So we're basically throwing out the results of the tests if the server doesn't return a connection. I checked how many tests in dc.rs actually return a Connection and it seems like it's only 2/13, which makes me think this was unintentional. So, to restate, in only 2/13 dc tests are we actually performing the checks that are written.

Solution:

We need to dig into why we're ignoring the None branch. I found this while looking into some other issues and haven't had time to investigate. If this is expected behavior then we need some sort of comment since it looks very unintentional.

Actually, I'm finding more issues/inaccuracies related to the dc tests. Just going to list them here until someone has time to fix them:

1. Settings for dc-quic endpoints in the tests aren't accurate. The existing dc-quic recv and send socket queues are only large enough to hold a single packet. This means that you can only read and send a single datagram per wakeup.
2. When the a network mtu is set for a test, the MTU builder is set to the network mtu setting, which makes no sense. These probably should be using dc-quics actual MTU settings: (I just realized an issue is already open for this: s2n-quic-tests's dc doesn't reproduce configuration of s2n-quic-dc::psk #3008)