feat!: use Fetch API for HTTP transport

[kahirokunn]

Fixes: #534

Proposed Changes

Use the Fetch API for the built-in HTTP transport.

Description

This removes the Node-only HTTP imports that cause browser bundling failures. httpTransport() returns the native Fetch Response and the handled body. Non-2xx responses, aborts and network failures reject with HTTPTransportError. The transport also accepts Fetch options, response handlers and abort signals.

See API_TRANSITION_GUIDE.md for the breaking changes and migration examples.

[shiva]

Firstly, thanks for taking the initiative for this big change! We need to bring this SDK to modern times, and I very much appreciate the effort. Continue to work with me, so we can balance improvements against taking too much dependency/inflating the API surface.

The change fixes #534, the typed errors and migration guide is clear. The test coverage is strong.

1. Size of the API change
This is a lot more than a plain fetch wrapper needs: 13 new exports, plus generics and overloads that only the per-send response handler requires. Once 11.0 ships, each is hard to remove. Which use cases need them?

2. Do we need all the overrides?
Per-send headers and signal are clearly useful. The per-send responseHandler and the transport-level signal look like the least needed. The transport owns how and where we connect; a send owns only what's specific to that event.

Setting	Belongs to	Overridable per send?
URL (the sink)	transport	No. For another URL, make another transport
fetchOptions (proxy, mTLS, redirect)	transport	No
responseHandler (how replies are read)	transport	No
headers (auth, trace id, idempotency key)	send	Yes
signal (cancel or time out this send)	send	Yes
ce-*, content-type, content-length, host	the event or fetch	No, at either level

Instead of header per-send shouldn't be header per message?

On this rule, the following could go:

• the per-send responseHandler and its types and overloads, and
• the transport-level signal, which stays aborted for the life of the transport.

@duglin I'd like your feedback here on how far we want to change the API, and allow overridability. By opening it too much, we become a generic http library vs a cloudevent specific one.

[kahirokunn]

Firstly, thanks for taking the initiative for this big change! We need to bring this SDK to modern times, and I very much appreciate the effort. Continue to work with me, so we can balance improvements against taking too much dependency/inflating the API surface.

The change fixes #534, the typed errors and migration guide is clear. The test coverage is strong.

1. Size of the API change This is a lot more than a plain fetch wrapper needs: 13 new exports, plus generics and overloads that only the per-send response handler requires. Once 11.0 ships, each is hard to remove. Which use cases need them?

2. Do we need all the overrides? Per-send headers and signal are clearly useful. The per-send responseHandler and the transport-level signal look like the least needed. The transport owns how and where we connect; a send owns only what's specific to that event.

Setting Belongs to Overridable per send?
URL (the sink) transport No. For another URL, make another transport
fetchOptions (proxy, mTLS, redirect) transport No
responseHandler (how replies are read) transport No
headers (auth, trace id, idempotency key) send Yes
signal (cancel or time out this send) send Yes
ce-*, content-type, content-length, host the event or fetch No, at either level
Instead of header per-send shouldn't be header per message?

On this rule, the following could go:

• the per-send responseHandler and its types and overloads, and
• the transport-level signal, which stays aborted for the life of the transport.

@duglin I'd like your feedback here on how far we want to change the API, and allow overridability. By opening it too much, we become a generic http library vs a cloudevent specific one.

@shiva Thank you for the review!

I've reduced the new exports from 13 to 5 and removed the per-message responseHandler and transport-level signal.
I've also blocked overrides of existing CloudEvents headers and rejected host and content-length. Valid CloudEvents headers can still be added.