Decrease allocations in encode loop.

[Lukasa]

Motivation

While investigating performance of HTTP/2 I noticed a substantial number
of allocations occuring in a hot loop in header compression. Specifically
I set up a simple harness that encoded headers 100 times, and then ran
that harness 10k times. This harness ended up performing 17 million
allocations, which is frankly a bit too high!

The fact that the number of allocations was in the millions suggested that
we were allocating some resources per header encode. That's not good:
assuming the target ByteBuffer is big enough we should not need to
perform new allocations to encode headers.

The allocations came from two places. Firstly, we were allocating in the
HeaderTableStorage.indices(matching:) function. This was because that
operation was returning a lazy collection, which required multiple heap
allocations for the closure contexts. Those needed to be eliminated.

Secondly, we were triggering a CoW of the ByteBuffer passed in to
encode(). This is the result of a complex bit of control flow that
fundamentally meant that the buffer was held in two places in that
method.

Removing these two sources of allocations dropped the count in my test
from 17 million to 176k, a decrease of 100x. We also saw a speed boost
of nearly 66% in terms of runtime of the microbenchmark.

Modifications

• Removed HeaderTableStorage.indices(matching:)
• Implemented `HeaderTableStorage.closestMatch(name:value:), containing
  the repeated logic of the body of the two loops over the header
  indices.
• Used swap() and an empty byte buffer to ensure that encode does not
  cause a CoW operation.

Result

Much faster and more memory efficient header encoding.

[weissi]

great work @Lukasa