This adds support support for the nextjs assetPrefix option to the nextjs SDK. Currently, if users set this option, it changes the filepaths in their client-side stacktraces in a way not reflected in their release artifact names, causing sourcemaps not to work. This fixes that by using RewriteFrames to modify the stacktrace filepaths so that they'll match the release artifacts.

Notes:

• Initial work on this was done by @tomas-c in fix(nextjs): handle assetPrefix #6241. (Thanks, @tomas-c!) The approach taken there was to change the way the client-side release artifacts are named, rather than to change the filenames in the stacktrace as is done here. After discussions with @lforst, I decided to take this approach because it's more consistent with what we already do on the server side. There, we use RewriteFrames, and we mutate the filepaths to start with app:///_next. This mirrors that for the client side.

• In the process of working on this, I discovered that we currently have a bug, caused by the way we handle the basePath option when naming release artifacts, including it at the beginning of all artifact names. Unfortunately, it's not included in stacktrace filenames, so this is a mistake.

  On the server side, this makes the stacktrace filenames and the artifact filenames not match, meaning sourcemaps for people using that option are currently broken for all sever-side errors. (The reason this hasn't been more obvious is that in the node SDK, we harvest context lines at capture time, rather than relying on sourcemapping to provide them. Also, server-side built code is transpiled but not bundled or mangled, making even un-sourcemapped code much easier to read than it is on the browser side of things.)

  On the browser side, it doesn't break sourcemaps, but only because it turns out that nextjs copies basePath over into assetPrefix if a user provides the former but not the latter. As mentioned, basePath doesn't appear in stacktrace filepaths, but assetPrefix does, which is what led us to think was working.

  To fix this, this PR stops including basePath in artifact filenames. As a result, on both the server-side and client-side, all artifact filenames are now of the form ~/_next/..., rather than some looking like that but others looking like ~/basePathValue/_next/....

• Part of the work here was figuring out how distDir, basePath, and assetPrefix interact, and where they show up in stacktrace filepaths. Just so it's written down somewhere, the answer is:

  • basePath - Never shows up in stacktrace filepaths, except insofar as it's copied into assetPrefix if it's set and assetPrefix isn't, in which case assetPrefix acts like it's path-only.
  • distDir - Server-side stacktrace filepaths are of the form <pathToProjectDir>/<distDir>/server/... (or <pathToProjectDir>/<distDir>/serverless/...). Example: /path/on/host/machine/someDistDir/server/....
  • assetPrefix - If assetPrefix is a full url, client-side stacktrace filepaths are of the form <assetPrefixHost>/<assetPrefixPath>/_next/static/.... If assetPrefix just a path, stacktrace filepaths are of the form <host>/<assetPrefixPath>/_next/static/.... Examples: http://some.assetPrefix.host/some/assetPrefix/path/_next/...` and http://some.normal.domain/some/assetPrefix/path/_next/....

Fixes #4174.