Optional limits on address and data length

[avieth]

A transport has two optional limits:

• Address length: refuse to read peer addresses longer than this many bytes.
• Receive length: refuse to read data from a peer longer than this many bytes. If a peer attempts to send an address of length exceeding the limit, the connection will be refused (socket will close). If a peer attempts to send data on a lightweight connection exceeding the limit, the heavyweight connection which carries that lightweight connection will go down. The peer and the local node will get an EventConnectionLost.

A test case is included.

Some changes in here are also present in #51. Will resolves conflicts once either of them is merged.

[dcoutts]

@avieth actually I think there's a further simplification we can make here. Instead of using a Maybe for the maximum size we can just always supply a max size, but the default can still be maxBound if we want to. That'd simplify the code path in recvWithLengthLimited since there would only be one code path. Similarly, the limits in TCPParams would not be Maybes and the defaults can be 300 and 4GB (or I'd argue we should have something more sane for the latter like 1Mb)

[avieth]

actually I think there's a further simplification we can make here. Instead of using a Maybe for the maximum size we can just always supply a max size, but the default can still be maxBound if we want to. That'd simplify the code path in recvWithLengthLimited since there would only be one code path. Similarly, the limits in TCPParams would not be Maybes and the defaults can be 300 and 4GB (or I'd argue we should have something more sane for the latter like 1Mb)

I'm in favour of this.

[facundominguez]

LGTM @dcoutts, do you want further changes?

[avieth]

I've made the limits non-optional, using maxBound :: Word32 as the defaults.

I've also included a patch to limit the size of Received chunks. This will be useful in tandem with a more sophisticated QDisc: knowing that the maximum number of bytes in any given event is some manageable number (far less than the current 2^32) a QDisc can be more effective at limiting the amount of data that a peer can push into the system. One could argue that this isn't necessary: the existing receive limit is also a bound on the size of a Received event payload. But then, it could be useful to allow relatively large payloads, while demanding more granular events for the benefit of the QDisc.

[facundominguez]

It looks like this PR needs to rebase master in order to have CI passing.

[facundominguez]

Thanks @avieth!