Enabling more Stream functionality

[halzy]

This PR is rebased it off of the PR #2586 so that it's easier to see what that PR does.

This is useful when compiling to WASM for the Cloudflare Workers:
https://developers.cloudflare.com/workers/runtime-apis/streams

Added Unstable WebIDL:
unstable/ReadableStreamDefaultReader.webidl
unstable/ReadableStreamGenericReader.webidl
unstable/QueuingStrategy.webidl
unstable/ReadableStreamBYOBReader.webidl
unstable/TransformStream.webidl
unstable/WritableStream.webidl
unstable/WritableStreamDefaultWriter.webidl

[halzy]

TransformStream is useless without these.

[halzy]

This type isn't created by the API user. It would benefit from #1793 and the setters are not useful.

[halzy]

Same here, not constructed by user, needs getters not setters.

[alexcrichton]

Seems reasonable to me! I don't know anything about these APIs myself so I'd basically just be trusting you about the stable/unstable. Was there anything else you wanted to do here before merging though?

[halzy]

Seems reasonable to me! I don't know anything about these APIs myself so I'd basically just be trusting you about the stable/unstable. Was there anything else you wanted to do here before merging though?

@alexcrichton I've had a hard time determining how stable they are. The spec is a living standard and I've been relying on MDN to know if they're 'experimental' or not. After reviewing them again, I'll move them all to unstable as MDN lists the methods of ReadableStreamDefaultReader as experimental.

[halzy]

I believe this is in a good state for merging now.

[alexcrichton]

This is unfortunately a breaking change to the get_reader and get_reader_with_options APIs. Is there a way to avoid that? Or otherwise do you think it's ok to break things?

[halzy]

This is unfortunately a breaking change to the get_reader and get_reader_with_options APIs. Is there a way to avoid that? Or otherwise do you think it's ok to break things?

If a return type is not know to the code generator, it'll return a JsValue. When those types are then known, the return types should change because it's more correct. But what if the return type happens to be unstable?

If the return type is unstable we could mark the function as unstable, but that could then take a stable function that had unknown return types and make it unstable. That seems undesirable.

In this case we're lucky that there are 2 return types possible and the code generator end up resolving to Object. I think it's OK to break this as it's more correct. Users were likely casting from JsValue into either of those unstable types that they hand-rolled in their own project.

[alexcrichton]

Ok seems reasonable to me! This defintely seems like a bug in the code generator though...