[Feature Request]: Expose more powerful options for configuring network requests

[max-stytch]

This is a tracking ticket to determine usecases & possible solutions where we want to allow callers greater control over configuring network requests.

Usecases

U1: NextJS Fetch Integration

NextJS 13's monkeypatching of fetch allows applications to control caching at a low level. As of #271 we disable this fetch caching, since it is not applicable to a large # of our endpoints (anything that starts a login transaction, or completes one). However, it may be applicable to endpoints like GET /users/:userID.

This fetch behavior is controlled by passing in custom options to fetch.

[Update Oct 19] However, we can't target only the NextJS runtime behavior. The NextJS fetch behavior is incompatible with Cloudflare Workers behavior, which doesn't allow the cache key to be set at all! See #273

U2: Observability Integrations

Are there integrations with o11y tools like opentelemetry that we'd like to better support, or fail to play nicely? Let's track them here.

Possible Solutions

S1: Take in arbitrary fetch options per request

This would be fairly low lift, solve for U1 but probably not U2.

S2: Take in arbitrary fetch options at client construction time

This would be very low lift, but is unlikely to solve for U1, since cache considerations, timing, and invalidation are likely to be very different between different API endpoints. The same cache policy applied to Members should not apply to Organizations, for example.

S3: Allow caller to pass in custom fetcher implementation

This would be a medium lift, and would provide the most robust solution for power users. However, it means that our API is significantly more complex, and we're pushing that complexity onto our users instead of managing it ourselves.