test: add quic datagrams test

[achingbrain]

Adds tests for sending and receiving datagrams as strings and buffers from client->server and server->client.

Switches offset/length around in Uint8Array constructor call as otherwise we send empty datagrams which get ignored.

The test currently fails because the first datagram is received many times.

[achingbrain]

Opened as a draft because the tests don't pass currently.

[achingbrain]

@jasnell I found a bit of weirdness in the implementation.

It's mentioned in the test comments but if you call sendDatagram too soon after staring the session, this check returns false so the datagram is not sent.

I would have thought that datagrams would be sendable after the opened promise on the session resolves but it appears not.

After waiting for an arbitrary period the datagram is sent but is received multiple times. Is the user supposed to filter these duplicates out or is it an implementation bug?

Finally if you close the server listener without first closing any active sessions a segfault occurs. If you do close the sessions first, the promise returned from the listener .close() method resolves, but the process keeps running.

The segfault stack trace is:

----- Native stack trace -----

 1: 0x10456cf44 node::DumpNativeBacktrace(__sFILE*) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 2: 0x1046dbf98 node::Assert(node::AssertionInfo const&) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 3: 0x104aa6048 node::quic::Endpoint::local_address() const [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 4: 0x104aaa1e4 node::quic::Endpoint::Receive(uv_buf_t const&, node::SocketAddress const&) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 5: 0x104aa2964 node::quic::Endpoint::UDP::Impl::OnReceive(uv_udp_s*, long, uv_buf_t const*, sockaddr const*, unsigned int) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 6: 0x1063f1660 uv__udp_recvmsg [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 7: 0x1063efe74 uv__udp_io [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 8: 0x1063f6a6c uv__io_poll [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
 9: 0x1063d1fe8 uv_run [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
10: 0x10449d100 node::SpinEventLoopInternal(node::Environment*) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
11: 0x104765288 node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
12: 0x104764ef0 node::NodeMainInstance::Run() [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
13: 0x104639830 node::StartInternal(int, char**) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
14: 0x10463944c node::Start(int, char**) [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
15: 0x1069fa1c4 main [/Users/alex/Documents/Workspaces/achingbrain/node/out/Debug/node]
16: 0x1827d0274 start [/usr/lib/dyld]
FATAL ERROR: v8::HandleScope::CreateHandle() Cannot create a handle without a HandleScope

..so it looks like maybe the client is still sending the duplicate datagrams to the server even after the session has been closed.

[achingbrain]

The behaviour appears to be due to setting the NGTCP2_WRITE_DATAGRAM_FLAG_MORE flag here.

When it's set, we hit this branch and add the same datagram to the outgoing packet over and over again hence all the duplicates.

Setting the flag value to 0 makes ngtcp2_conn_writev_datagram return a positive value and the listener receives the datagrams and the test passes, though it still segfaults when trying to shut the server down afterwards.

[jasnell]

@achingbrain ... just FYI I haven't had the chance to take a look at this yet but I intend to soon! It will likely be in the next few days. Really appreciate your taking a look at this tho!