Fix stream() support for chunked event streams

[aron]

There's a subtle bug in the current Stream implementation where if the server emits lines in several chunks then we get "null" events in the async iterator.

For example:

event: output
id: 1
data: hello
-- chunk 2 --
data: world
-- chunk 3

event: done
id: 2
data: {}

Will result in:

SSE { id: 1, event: "output", data: "hello" }
SSE { id: null, event: null, data: "world" }
SSE { id: 2, event: "done", data: "{}" }

This PR fixes this, plus a few bugs in the Stream implementation:

• We now use the fetch() implementation provided to the Replicate constructor rather than the global.
• We raise an error if the stream endpoint does not respond with a 2xx status code.
• We now ensure that the decode() function in the Stream class processes full lines by retaining the last line of the current chunk and appending it to the start of the next chunk before splitting on newlines.
• Fixes the type definition for validateWebhook which returns a Promise<boolean> but is typed to return boolean.

[aron]

I think this is a bug, rather than a feature because it means that we always need to check event.event === "output" before accessing event.data. The toString function kind of hides this but it doesn't work with JSON.stringify().

I think actually we want to return the done event from the iterator rather than yielding it. Then the done iterator will look like:

expect(await iterator.next()).toEqual({ done: true, value: { event: "done", ... } });

[mattt]

That sounds reasonable to me. Any reason not to make that change to return for done?

[aron]

It's technically a breaking change, but unclear how much of an issue it would cause. There's nothing you can do with it except listen for it and ignore it.

[aron]

@mattt can we punt on the event: done piece for the moment while I give it some thought and get the bug fix in?

[aron]

Closing in favor of #214