Allocate receive buffer gradually instead of all at once

[r-n-o]

Summary & Motivation (Problem vs. Solution)

Followup to #527 -- instead of allocating 128MB we now allocate 2MB per connection, and scale by doubling the size if the receive buffer is full. This avoids attacks where the declared size is 128MB and the connection hangs.

How I Tested These Changes

Existing unit tests.

[cr-tk]

@r-n-o and I went over this internally.

The receive logic and buffer resizing looks good to me.

The 2^n buffer size steps at >= 2MiB should work well without too much buffer resizing overhead, while the < 2MiB case avoids a large buffer size overhead or any resizing for short messages.

With the new PR, malicious client connections now have to provide at least 2^(n-1) byte of message body data on the wire before the QOS side allocates a new buffer size of 2^n byte, for up to n = 27 in the 128MiB case.

We clarified the documentation around the maximum allowed input size and MB<>MiB. We also discussed the validity of messages with a body length of 0, which are accepted by the current code.

Note that recv() internally uses the length of the available mutable message buffer that is known on the Rust side when translating the call to the actual recv, which avoids overflows while receiving a new chunk of data.

Overall, I think this is ready for approval and merge.