Defer allocating reassembly buffers in DTLS

When reassembling a DTLS message, we allocate:
- A buffer to hold the reassembled message
- A bitmap to track what portions of the message has been received

This means that once we receive a single fragment of the message, we
allocate this data. While bounded, it would be nice to wait until the
peer has sent us that much data first.

If we instead tracked the fragments individually, the memory would be
proportional to the total data received, but efficient reassembly
becomes tricky.

Square this circle by using both representations. While we've received
so few fragments that the message cannot possibly be complete, just
store the fragments separately. Once enough data is received, switch to
the reassembly buffer representation.

Fixed: 545614387
Change-Id: Idbf6637208b0e9fca5d9ea1349f5b6a5cc2e23a0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/100827
Presubmit-BoringSSL-Verified: boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Lily Chen <chlily@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>