Command + control benchmarks

[piercefreeman]

Follow up to #12.

One could implement this logic separately in Playwright through request interception. There are a few benefits to this:

• Inline node support; can make use of global logic and shared data structures
• Direct communication between browser -> server, no need for a socket based relay. Anecdotally in popdown adding a passthrough MITM server did slow things down.

However, direct Playwright commands have a few drawbacks:

• Requires chatty communication between node (playwright core) and chromium dev tools. To work with local caching we would need to intercept every outbound request and potentially send back the content.
• Some requests aren't successfully captured by requests - see [BUG] [Chromium/WebKit] Request object does not contain postData for file/blob microsoft/playwright#6479 and [Question] How can I trigger a service worker update by modifying the HTTP response? microsoft/playwright#14711 for examples. Most web workers require additional handling and support in Chromium.
• Force multiprocessed / multithreaded chromium requests to run sequentially through node's single-threaded runtime
• Can't change the end proxy on the fly, requires a new context to be created.

const browser = await chromium.launch({
  // Browser proxy option is required for Chromium on Windows.
  proxy: { server: 'per-context' }
});
const context = await browser.newContext({
  proxy: { server: 'http://myproxy.com:3128' }
})

This ticket tracks writing a benchmark comparing the speed of a separate proxy server versus similar functionality written in Node.