Handle buffers directly instead of using "bl"

[zertosh]

bl does a lot, but request's needs are pretty simple. This PR removes bl in favor of operating on buffers directly. There is no change in functionality here - bl also calls Buffer.concat when slicing an all buffer BufferList.

[mikeal]

If i recall, the original thinking was "maybe we can eventually just pass the bl instance to the callback" instead of doing the concatenation and underlying memcopy of the buffers.

Turns out it's just too difficult to "pretend" to be a Buffer reliably and integrate with instanceof checks and Buffer.isBuffer().

[mikeal]

To be clear, I'm +1 on the premise, but I haven't had the time to code review quite yet.

[zertosh]

Thank you, I appreciate the background.

For context, this is just one of many more upcoming PRs. My end goal is to improve request's load time. Right now it's taking ~90-100ms - which is not a trivial amount. There are common cases in popular projects where request is in the load path, but it's not used every time. I'm investigating other optimizations like lazy loading request's deps and lazily instantiating the various support classes.

[mikeal]

I wonder why the code coverage went down, this still hit a bunch of our existing tests :(

[mscdex]

This could be improved by keeping a running total that's passed as the second argument to Buffer.concat(). It saves time by not having Buffer.concat() loop through all of the Buffers to find the total length.

[zertosh]

I've updated the PR by rebasing onto master and adding the length tracking as suggested by @mscdex

[mscdex]

Minor nit: perhaps to be consistent with the changes down below, bufferLength = 0 should be added after this line as well?

[zertosh]

done!

[mscdex]

LGTM and CI is green :-)

[simov]

@zertosh 👍
@mscdex you have a pending invitation to the request team from a long time ago, let me know if you want me to send you another one 👍