Better [documented?] support for automated e2e tests

[ari-becker]

Goals

As a developer writing a Next.js application using next-auth / auth.js to handle authentication, I need to set up automated testing using tooling like Playwright for edge-to-edge tests.
The issue is, when automated tooling intersects with production-grade hosted authentication (e.g. Google login), automated tooling is typically blocked.
Therefore, only in development or testing environments, I would like to have an authentication provider that handles authentication entirely locally within the Next.js server process. This allows me to write application UI that uses hooks like getServerAuthSession() without treating the e2e test itself as an edge case.

By default, this would appear to be the credentials provider. However, because I use a database session strategy, the credentials provider is unavailable for this use. I could dynamically set the session strategy to jwt, but again, this further diverges the e2e suite from production, and further splits the codebase - for example, the implementation strategies for RBAC differ wildly between JWT and database sessions: https://authjs.dev/guides/basics/role-based-access-control#persisting-the-role which has knock-on effects if other parts of the application also depend on finding the RBAC information in the database (as JWT session strategies don't store users in the database either).

Non-Goals

No response

Background

Prior discussion:
#6828
#3765

Proposal

One option is to allow the credentials provider to create database sessions. I appreciate that this is unsafe in production; this could be expressed both in the documentation as well as requiring configuration like:

CredentialsProvider({
  dangerDatabaseUnsafeInProductionWarningAcknowleged: true
})

Another option is some kind of helper for setting up a fake OAuth identity provider in NextJS, so that auth.js can be configured with an oauth provider that points to e.g. http://localhost:3000/api/auth/testing/oauth/authorize etc., enabled only in testing and development. Which is unfortunately the direction I'm headed towards implementing on my own, unless there's a better way?