ReadableByteStream: pull + pullInto or just pullInto

[tyoshino]

Branched from #295 (comment)

Write the reason if we choose to have both.

[domenic]

At some point the plan was that if you do getReader().read(), it will pre-allocate a buffer for you of a given size, then pass that to pullInto. The size could be determined by an option to the constructor (maybe part of the strategy? or maybe part of the underlying byte source object).

That plan is definitely less powerful than having both pull and pullInto. But maybe it gives a significant enough simplification to be worth it? I am not sure.

[tyoshino]

Oh, right. I remembered that. But, that said, this problem is connected with #329. If the ReadableByteStream is designed to automatically allocate a buffer for reader.read() call, and if we implement an underlying byte source that may be able to pass an allocated buffer with its ownership to us (for example the identity transform being discussed in the issue), we want to pass through the buffer to the consumer. So, yes, it should be more powerful to leave the work to allocate a buffer up to the underlying source.

[tyoshino]

Current ReadableByteStream being redesigned at #418 has both pull and pullInto. When read(view) is called, via pullInto, the stream passes the TypedArray received from the consumer to the underlying source. For read(), pull is invoked and the underlying byte source allocates a TypedArray and enqueue()-s it. Allocation is now done by the underlying source.