feat(nextjs): Add spans and route parameterization in data fetching wrappers

[lobsterkatie]

This adds span creation and route parameterization to the experimental getStaticProps and getServerSideProps wrappers. In order to do the parameterization, we store the parameterized route( which is the same as the filepath of the page file) as a global variable in the code we add using the dataFetchersLoader and then pass it to the wrappers, which then replace the name of the active transaction with the parameterized route we've stored. It also adds basic error-capturing to the wrappers.

Open issues/questions (not solved by this PR):

• Because of prefetching, revalidation of static pages, and the like, the data fetching functions can run in the background, during handling of a route different from their own. (For example, if page A has a nextjs Link component pointing to page B, next will prefetch the data for B (and therefore run its data fetching functions) while handling the request for A. We need to make sure that we don't accidentally overwrite the transaction name in that case to B.
• There's more we should do in terms of error handling. Specifically, we should port much of the logic in withSentry into these wrappers also.
• Porting the error-handling logic will mean we need to deal with the domain question - how to keep reactivating the correct domain as we go into and out of data fetching and rendering functions.

(There are other items listed in the meta issue linked below, but the above are the ones directly relevant to the work in this PR.)

Ref: #5505

[lforst]

Great work! Just left some questions for me to understand better what we're doing.

[AbhiPrasad]

Can we make sure we align the operation names with https://develop.sentry.dev/sdk/performance/span-operations? If need be we can amend that spec to add new categories

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	19.38 KB (-0.02% 🔽)
@sentry/browser - ES5 CDN Bundle (minified)	59.99 KB (0%)
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	17.96 KB (-0.01% 🔽)
@sentry/browser - ES6 CDN Bundle (minified)	52.88 KB (0%)
@sentry/browser - Webpack (gzipped + minified)	19.73 KB (0%)
@sentry/browser - Webpack (minified)	64.21 KB (0%)
@sentry/react - Webpack (gzipped + minified)	19.75 KB (0%)
@sentry/nextjs Client - Webpack (gzipped + minified)	44.39 KB (0%)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	25.89 KB (0%)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	24.26 KB (-0.02% 🔽)

[lforst]

Ok as for the thing Abhi mentioned: I took a look at https://develop.sentry.dev/sdk/event-payloads/span/#attributes, and https://develop.sentry.dev/sdk/performance/span-operations/.

From what's already there, it IMO makes the most sense to have something like op: "render", description: "[dataFetchingFunction]: [route]". (fwiw, "render" isn't all that wrong since the file that calls the data fetching methods in the next.js repository is literally called "render.tsx")

We could also expand the JS framework operations by something nextjs.data, or nextjs.data.getinitialprops. I don't know if we would have to involve other teams in this.

Right now I would just go for the first approach so we don't block this PR and fix stuff up later if necessary.

[lobsterkatie]

Hmmm... I see your point, but given that I'm thinking we'll have spans for the actual rendering bit, I kinda feel like we should reserve that title for them. Of the examples already on our list, these data fetching methods feel most like a cross between django.middleware and django.view to me. I think your proposed names make a lot of sense, and IMHO I think we should just go for it because a) there is already precedent for individual frameworks having their own span names, and b) this is still behind a flag, so the stakes are low.

[AbhiPrasad]

yup, and we can always change it if product requires us to.

[lforst]

Sounds good!