feat: shrink allocations when setting new elements

[Stebalien]

bytes.Buffer will often over-allocate. Here, we copy to an exact-sized buffer to avoid this. We'll pay some extra copying cost, but we can at least avoid the allocation overhead with a buffer pool in most cases.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 83.33333% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 53.32%. Comparing base (f6a28b2) to head (c64ccd1).

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #90      +/-   ##
==========================================
+ Coverage   52.94%   53.32%   +0.38%     
==========================================
  Files          13       13              
  Lines        1309     1324      +15     
==========================================
+ Hits          693      706      +13     
- Misses        464      465       +1     
- Partials      152      153       +1     

Files	Coverage Δ
amt.go	62.14% <66.66%> (ø)
util.go	90.00% <86.66%> (-10.00%)	⬇️

[rvagg]

ok, checking my understanding: I think what we're doing here is (1) using bytes.Buffer to do efficient allocation of bytes when we don't know up-front what we'll need, (2) using a pool so we're not going to suffer from the consistent over-allocation bytes.Buffer does every time we use one, and (3) copy the bytes into a fixed length slice so we end up with precisely what we need and can reuse the bytes.Buffer without concern.

[Stebalien]

Exactly.

[rvagg]

this looks good to me, and it works, and is faster for the heavy migration work, which is unexpected I think but good news