This test doesn't compile in a way that reveals a problem with the design. The
verification service takes a `Request<'msg>` parameterized by the message
lifetime, and returns a future unconstrained by the message lifetime (it hashes
upfront to avoid requiring that `'msg` outlive `call`). But the `Batch`
middleware has the verification service working on its own task, so how can we
ensure that the message lives long enough to be read by the worker task?
The name "Buffer" is changed to "Batch" everywhere, and the worker task is rewritten.
Instead of having Worker implement Future directly, we have a consuming async run() function.
There's a lot of functional overlap between the batch design and tower-buffer's
existing internals, so we'll just vendor its source code and modify it.
If/when we upstream it, we can deduplicate common components.
Henry de Valence