Fix ReadableStream constructor if not getting a promise as startResult

[calvaris]

In the examples we have cases where the result of invoking the start
is undefined and we treat it as something acceptable, therefore the
constructor should be prepared to operate in that case.

I guess this should also apply to other cases, like the WritableStream constructor, cancel functions, etc.

[domenic]

The next line resolves startResult as a promise, so this is not correct.

[calvaris]

Hi Domenic,

I acknowledge that we forgot to add the code to set this@[[started]] to true.

The problem is other though. As I explained, in the shown examples, sometimes a promise is not returned or resolved, sometimes, even nothing is returned (which means startResult becomes undefined). The question is for those cases, how will the current algorithm behave?

We considered that if startResult is undefined, we should proceed to fulfillment and that's why we went to pull, though I already acknowledged that we forgot about the [[started]]

[domenic]

No, you're missing what I said. The next line contains

Resolve startResult as a promise:

so in the case of startResult undefined, the promise that we're doing "on fulfillment"/"on rejection" on will be equivalent to Promise.resolve(undefined).

[calvaris]

The thing is that I tried to find in the Promises spec is what happens when undefined is returned as a promise, but if you say it is like that then it makes sense. Thanks!