Bugfix: Propagate Spring request context to virtual thread pool

[lorenzsimon]

Pull request checklist

• Please read our contributor guide
• Consider creating a discussion on the discussion forum
  first
• Make sure the PR doesn't introduce backward compatibility issues
• Make sure to have sufficient test cases

Pull Request type

• Bugfix
• Feature
• Refactoring (no functional changes, no api changes)
• Build related changes
• Other (please describe):

Changes in this PR

Setting dgs.graphql.virtualthreads.enabled=true breaks Spring request context propagation because the configured AsyncTaskExecutor uses virtual threads which don't inherit the RequestAttributes stored in thread local.

The consequence is for example that DGS handler methods can't access request scoped beans which are required for many use cases like DB table auditing.

We can propagate the request context to virtual threads by using a custom ThreadLocalAccessor which restores the thread local when the virtual threads switch context.

Alternatives considered

We currently provide our own AsyncTaskExecutor. However, propagating the Spring request context should be included in the default configuration since the framework already has the dependency on Spring Web and core featured don't work without it.

[kilink]

An implementation of a ThreadLocalAccessor for RequestAttributes already exists in Spring itself, and it handles additional edge cases. You're also able to load it today using SPI, but maybe it should be installed by default. @paulbakker thoughts?