feat: implement the defineNetwork API

[kettanaito]

• Drafted in The `defineNetwork()` API #2488
• Ported from feat: support cross-process interception via setupRemoteServer #1617
• Related to Support for Cloudflare Workers runtime #2637

Changes

• Rewrites the way the SetupApi behaves by introducing: network frames, sources, controllers, and defineNetwork.
• Handlers are now stored in a kind-based map. This should improve the performance during handler lookup since it becomes O(1).

Usage

The introduces APIs are meant to be used from the explicit msw/future export path. The path itself isn't documented as the APIs are considered experimental until the next major release.

Roadmap

• Ensure the changes are backward-compatible
  • I removed HandlersKind and just inlined them in the handler classes.
  • I removed __kind private field from handler classes and made kind public. This is a safe change as nobody should be using these fields.
• Passing handlers as both handlers and the constructor argument for the handlers controller seems odd. Choose just one?
  • Merged two into a single handlers option. After all, handlers are only needed as the input to the controller.
• Consider higher-level utilities to create things like custom setupServer. The defineNetwork API is rather low-level. Export NetowrkOptions to the user can just override some of them?

import { defineNetwork } from 'msw'
import { defaultNetwork } from 'msw/node'

// Create a custom "setup*" wrapper.
function setupCustomApi(...handlers) {
  return defineNetwork({
    ...defaultNetwork,
    ...customizations,
    handlers,
  })
}

// Use it as you normally would use "setup*" APIs.
const network = setupCustomApi(...handlers)
network.enable()

• Export createSetupServerCommonApi or its alternative. That's a crucial part of extending the default behaviors.