• Adds a new nest root module that can be used to setup the Nest SDK as a replacement for the existing setup (with a function). Instead of calling setupNestErrorHandler in the main.ts file, users can now add SentryModule.forRoot() (feedback about the name is definitely welcome) as an import in their main app module. This approach is much more native to nest than what we used so far. This root module is introduced in the setup.ts file.
• This root module is exported with a submodule export @sentry/nestjs/setup, because the SDK now depends on nestjs directly and without this the nest instrumentation does not work anymore, since nest gets imported before Sentry.init gets called, which disables the otel nest instrumentation.
• Judging from the e2e tests it seems that this new approach also resolves some issues the previous implementation had, specifically this issue seems to be resolved. The e2e test that was in place, just documented the current (wrong) behavior. So I updated the test to reflect the new (correct) behavior.
• I updated all the test applications to use the new approach but kept a copy of the nestjs-basic and nestjs-distributed-tracing with the old setup (now named node-nestjs-basic and node-nestjs-distributed-tracing respectively) so we can still verify that the old setup (which a lot of people use) still keeps working going forward.
• Updated/New tests in this PR:
  • Sends unexpected exception to Sentry if thrown in Submodule
  • Does not send expected exception to Sentry if thrown in Submodule and caught by a global exception filter
  • Does not send expected exception to Sentry if thrown in Submodule and caught by a local exception filter
  • Sends expected exception to Sentry if thrown from submodule registered before Sentry
• To accomodate the new tests I added several submodules in the nestjs-with-submodules test-application. These are overall similarly but have important distinctions:
  • example-module-local-filter: Submodule with a local filter registered using @UseFilters on the controller.
  • example-module-global-filter: Submodule with a global filter registered using APP_FILTER in the submodule definition.
  • example-module-global-filter-wrong-registration-order: Also has a global filter set with APP_FILTER, but is registered in the root module as first submodule, even before the SentryIntegration is initialized. This case does not work properly in the new setup (Sentry should be set first), so this module is used for tests documenting this behavior.
• Also set "moduleResolution": "Node16" in the nestjs-basic sample app to ensure our submodule-export workaround works in both, default and sub-path-export-compatible TS configs as was suggested here.

Sorry, this PR got a bit long (but most of it is copying existing test applications into new folders).