fix(transport/packet): don't (mutably) borrow data multiple times

[mxinden]

Merges into mozilla#2385.

[larseggert]

LGTM.

I've been wondering if going with &mut slices into data for token, etc. would be a defensible choice for PublicPacket, since we then convert it into a non-&mut DecryptedPacket anyway. Maybe we should do that conversion earlier?

[mxinden]

I am not sure I am following. Are you suggesting to split off dcid, scid and token off of &mut data earlier, thus make it a single immutable reference each?

Converting all of data into an immutable reference can only be done after decryption, correct? Otherwise it could never be in-place, i.e. back into data.

[larseggert]

Sorry for being unclear. If I understand it correctly, with this PR we're doing multiple (smaller) heap allocation for the various bits of the struct that can't be slices into data anymore. I wonder if that is actually worse. So I'm looking for ways to avoid those new allocations. One way would be to still let them be mut slices during parsing/decryption, but then make them non-mut slices afterwards, i.e., on DecryptedPacket.

[mxinden]

Got it. Thanks.

Before optimizing these small allocations, I would suggest building a benchmark first, which shows that those allocations are significant.

Also note, ConnectionId uses a SmallVec. Unless the SmallVec limit is reached, the data goes on the stack, i.e. is not allocated on the heap.