The ReadableStreamPipeTo AO requires reading all chunks from a stream.
There actually isn't an AO defined to do that, so the "read all bytes"
implementation was changed to provide each chunk in a vector in commit
12cfa08a09.
This change makes reading all bytes a bit more uncomfortable in normal
use cases, as we now have to manually join the vector we receive. This
can also cause churn with huge allocations.
So instead, let's just provide an ad-hoc callback to receive each chunk
as they arrive.
With this change, we now have ~1200 CellAllocators across both LibJS and
LibWeb in a normal WebContent instance.
This gives us a minimum heap size of 4.7 MiB in the scenario where we
only have one cell allocated per type. Of course, in practice there will
be many more of each type, so the effective overhead is quite a bit
smaller than that in practice.
I left a few types unconverted to this mechanism because I got tired of
doing this. :^)
This is not to the specification, but as the FIXME comment for the
function states, we need it to be able to properly interface with the
FileAPI spcification, which seems to have not been updated to the non
promise based API.
This algorithm is used by ReadableStreamDefaultReader to read all bytes
from a given stream. Currently the algorithm used is somewhat naive as
it is recursive, but given the initial use of this reader, it should not
be a problem.
