Don't allow small units of application data to keep large packets in memory

[Ralith]

Quinn uses zero-copy refcounted Bytes for most processing of incoming data. At the extreme, a hostile peer could send numerous stream frames containing a single byte in a packet padded to MTU size. We could combat this by heuristically opting to copy segments of application data into freshly allocated memory when they fall below a certain proportion of the packet, or when a packet consists of a small proportion of application data, or similar.

[Ralith]

Peer Denial of Service:

While there are legitimate uses for all messages, implementations SHOULD track
cost of processing relative to progress and treat excessive quantities of any
non-productive packets as indicative of an attack. Endpoints MAY respond to
this condition with a connection error, or by dropping packets.

Something to consider if exceptionally unreasonable packet constructions are detected, although we probably want to be forgiving of mildly buggy QUIC implementations.

[Ralith]

@carllerche has discussed the possibility of using Bytes with a custom allocator that's able to efficiently free random slices of an allocation, which would solve this problem very handily indeed.