[v9] Make Next.js withSentryConfig always return an async function

[lforst]

Description

sentry-javascript/packages/nextjs/src/config/withSentryConfig.ts

Lines 23 to 25 in f4c5900

	// TODO(v9): Always return an async function here to allow us to do async things like grabbing a deterministic build ID.
	export function withSentryConfig<C>(nextConfig?: C, sentryBuildOptions: SentryBuildOptions = {}): C {
	const castNextConfig = (nextConfig as NextConfig) || {};

Looking forward, we need the returned function to be async to be able to grab a build-ID from the Next.js user option, so that we can always have a good release value when Turbopack prod builds ship.

[lforst]

I am contemplating ditching this. There is a 100% chance this is gonna majorly (pun not intended) annoy a non-trivial amount of users and by extension myself via dealing with issues.

The original reason why I found this necessary is that today we rely on the Next.js buildId as a fallback value when generating release names. The buildId is passed via the buildContext.buildId arg to the webpack() hook in Next.js. With Turbopack we cannot use said hook anymore.

Forward-looking, I thought that if we made the return value of withSentryConfig async we can use the asynchronicity to manually either execute a user-provided https://nextjs.org/docs/app/api-reference/config/next-config-js/generateBuildId or fall back to providing our own.

Now, fast forward to the present, I had the thought of why we should even do that at all. In pretty much all other SDKs we just don't rely on anything like build IDs at all and the world keeps turning. Instead, what I think we'll do is instead just ditch the buildId and as fallback execute git rev-parse --short HEAD synchronously. This should be good enough for the majority of cases. In case we are not able to determine a release value we can print a warning (TBD whether we should do so cause it causes mental setup overhead).

[lforst]

Ditching this issue in favor of #14940