Perf: replace LimitChunkCountPlugin with more naive MergeChunksPlugin

Use more naive implementation of `MergeChunksPlugin` to concatenate all chunks in a single `server-main.js` bundle when building for server, in place of `LimitChunkCountPlugin` which seems to have quadratic runtime complexity and appears to be very slow for builds that include hundreds of async chunks (vs linear in the `MergeChunksPlugin` case).

Before:
```
[client] Build completed in 4.15s
[server] Build completed in 40.967s
```

After:
```
[client] Build completed in 4.195s
[server] Build completed in 6.801s
```

Fix React Router history bug where basename is not applied to initial…

… server render

In the React Router 5 implementation, when the server history object was created, the prefix was prepended to the current URL: https://github.com/uber/fusionjs/pull/1409/files#diff-b9d2e3755ea5d8daffc083230c68bfcea742135f9fca8a8aa7f54d13467c6017L103

This behavior was incorrectly removed in the RR6 implementation. The history location should always have the basename/prefix as part of the URL since that's what React Router expects.

Also include a small fix to fusion-plugin-apollo where if we are in dev mode, to log out SSR errors the way we do in fusion-react. This is so the errors show up in dev.

Co-authored-by: shYkiSto <[email protected]>

Add missing fusion-cli test fixtures (#776)

Update React to 18.2.0

Updates React to 18.2.0 across all packages. This is a devDependency upgrade for all packages. This is a peerDependency package upgrade only for the core packages that actually changed or incorporate React 18 features. For all other packages they will maintain a peer dep of >= 16.x until they otherwise to be bumped.

Error reporting improvments

The goal is to provide a platformized way to distinguish between errors at the Fusion layer.

Today, errors are handled in one generic manner. Whether they are client type errors (ie validation, not found) or server type errors (ie authorization, server failures), these errors are logged the same and frontend applications classify them all the same without custom handling.

Having these errors undistinguished creates a difficulty in filtering out specific error types that require different handling. This handling includes alerting on some error types but not others. For example:

Co-authored-by: shYkiSto <[email protected]>

Prevent dev runtime from crashing upon HMR error

Prevent development runtime from crashing miserably in an event of subsequent `ready` event received from the `ChildServer`. Also, force kill the underlying `ChildServer` process when terminating gracefully to make sure it does not spam to `stdout` after the dev process's terminated (often a case when the termination signal received, while the `ChildServer`'s still starting up in the background).

Bundle packages that could not be resolved at build time

Update webpack externals configuration, so that we fallback to webpack to handle the dependency in case its absolute path could not be resolved using the node.js resolver at build time (as opposed to assuming that the dependency may be available later at runtime). This also ensures a failing build in case the requested module is missing, which in turn prevents bad deployments using "defective" build artifacts.

This specifically fixes a scenario where the requested package is a local workspace that requires some build transforms, as it is consumed directly from sources (e.g., a local workspace authored in TypeScript).

Use empty source map with worker-loader

Reverting a hack that was implemented in https://github.com/uber/fusionjs/pull/1489 to fix a module name collision in generated source maps, as modifying the import path by appending querystring is not compatible with the resolution logic specified for "exports" field, where the package consumers must use exact import paths according to how the package author has it defined in the "exports" field in the package.json. E.g., for [@duckdb/duckdb-wasm](https://github.com/duckdb/duckdb-wasm/blob/15c8075b5f82d3d32386c5c1cd425b5473524de6/packages/duckdb-wasm/package.json#L96-L146)
```
{
  "...": "",
  "exports": {
        "./dist/duckdb-browser-mvp.worker.js": "./dist/duckdb-browser-mvp.worker.js",
        "...": ""
  }
}
```

The import must take form of `import from '@duckdb/duckdb-wasm/dist/duckdb-browser-mvp.worker.js'`, and `import from '@duckdb/duckdb-wasm/dist/duckdb-browser-mvp.worker.js?workerUrl=true'` is not allowed

Here's Node.js's `require.resolve()` output:
```
Welcome to Node.js v16.15.0.

> require.resolve('@duckdb/duckdb-wasm/dist/duckdb-browser-mvp.worker.js')
'~/test-dd/node_modules/@duckdb/duckdb-wasm/dist/duckdb-browser-mvp.worker.js'

> require.resolve('@duckdb/duckdb-wasm/dist/duckdb-browser-mvp.worker.js?workerUrl=true')
Uncaught:
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './dist/duckdb-browser-mvp.worker.js?workerUrl=true' is not defined by "exports" in ~/test-dd/node_modules/@duckdb/duckdb-wasm/package.json
    at __node_internal_captureLargerStackTrace (node:internal/errors:465:5)
    at new NodeError (node:internal/errors:372:5)
    at throwExportsNotFound (node:internal/modules/esm/resolve:472:9)
    at packageExportsResolve (node:internal/modules/esm/resolve:753:3)
    at resolveExports (node:internal/modules/cjs/loader:482:36)
    at Function.Module._findPath (node:internal/modules/cjs/loader:522:31)
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:919:27)
    at Function.resolve (node:internal/modules/cjs/helpers:108:19) {
  code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}
```

The original issue seems to be fixable by resolving the `worker-loader` using empty source map for the "virtual" module it generates.

Upgrade enhanced-resolve to enable subpath exports in jest config

A newer version of `enhanced-resolve` supports [node subpath exports](https://nodejs.org/api/packages.html#subpath-exports) so in this PR I've upgraded to the latest release in fusion-cli. I noticed that the jest resolver is copied into `jest-resolver-fusion` package with a different `enhanced-resolve` version. Should that be updated as well?

Most of this upgrade was straightforward besides handing the `es5-ext` package paths. Enhanced-resolve will escape `#` characters in file paths. I did some digging in webpack and found that they are using the async resolve method that will include the unescaped path, but in the sync variant it will only output escaped. Before the unescaped path was available, webpack would regex replace the `\0#` substrings so that's what I've implemented here.

I tested this change in web-code by resolving `fusion-cli/enhanced-resolve` to `5.10.0` and patching `fusion-cli` with the changes included in this PR.

Phab revision: https://code.uberinternal.com/D7832723
Passing CI build: https://buildkite.com/uber/web-code/builds/248921

Use unique resource name with workerUrl

Append `?workerUrl=true` resource query to a "virtual" module created using `workerUrl()`. This intends to resolve an issue , where there're duplicate entries being generated in the source maps that reference the same resource path of imported worker script, which can not be represented in devtools accordingly.

```
// client-main.js.map
...
"/foo/bar/src/worker.js" ... (Changes to => "/foo/bar/src/worker.js?workerUrl=true")
"module.exports = __webpack_public_path__ + \"worker.js\";

// worker.js.map
...
"/foo/bar/src/worker.js" ...
"console.log('test worker');"
```