Instrument @nestjs/cache-manager in @sentry/nestjs

[nicohrubec]

https://docs.nestjs.com/techniques/caching

Potential solutions:

• Root Module: Add a module that provides a caching service with updated cache methods that users can use instead of the native nest cache mdoule. This takes away some of the hassle of manual instrumentation, but is still a lot of extra effort for users.
• Simple utility functions: We can write simple functions that wrap the native nest caching methods.This is already much better than manual instrumentation but still not too nice because users need to wrap everything.
• Fully automatic: Write a otel instrumentation that does automatic instrumentation of cache operations. This is definitely the ideal solution from a user perspective.

Notes from initial experimentation with fully automatic approach:
The CacheManager instances usually get injected in the constructor with the @Inject decorator. So my initial idea was to patch that decorator. I have experimented with this but not yet make it work. I initially expected that we would directly be able to access and patch the injected instance directly but instead we get the whole class as service and it is non-trivial to get the actual cache instance from that. There is a WIP PR open for this. Potentially we can try to monkey-patch the constructor and then check if there is a property of the CacheManager type on the service after the constructor was executed.

Another approach I tried was to "exploit" the DI system of nestjs. I was hoping that there is a singleton cache instance in the DI container that is being used wherever the user injects a cache instance. So I added a service to the root module that injected the cache manager and proxied it. The hope was that this would carry to other service instances injecting the cache in the same application but did not work out.