feat(nestjs): add instrumentation for NestJS microservice

[neilime]

Which problem is this PR solving?

• NestJS instrumentation currently only covers the core HTTP/controller lifecycle through @opentelemetry/instrumentation-nestjs-core, so Nest microservice applications and hybrid apps do not produce dedicated spans for microservice bootstrapping or message/event handlers.
• This change adds first-class NestJS microservice instrumentation while keeping the existing core-only package available as a compatibility path for current users.

Short description of the changes

• Add a new @opentelemetry/instrumentation-nestjs package that instruments both Nest HTTP controllers and Nest microservice handlers.
• Create spans for standalone and hybrid microservice startup (NestFactory.createMicroservice and app.connectMicroservice) and for message/event handler execution.
• Add Nest-specific attributes for microservice tracing, including handler callback, pattern, and transport information.
• Keep @opentelemetry/instrumentation-nestjs-core as a deprecated compatibility wrapper that delegates to the new package with microservice instrumentation disabled.
• Register the new package in @opentelemetry/auto-instrumentations-node and update the related README/docs.
• Add tests covering HTTP behavior, standalone microservices, and hybrid microservices.

[github-actions]

This package does not have an assigned component owner and is considered unmaintained. As such this package is in feature-freeze and this PR will be closed with 14 days unless a new owner or a sponsor (a member of @open-telemetry/javascript-approvers) for the feature is found. It is the responsibility of the author to find a sponsor for this feature.
Are you familiar with this package? Consider becoming a component owner.

[github-actions]

This package does not have an assigned component owner and is considered unmaintained. As such this package is in feature-freeze and this PR will be closed with 14 days unless a new owner or a sponsor (a member of @open-telemetry/javascript-approvers) for the feature is found. It is the responsibility of the author to find a sponsor for this feature.
Are you familiar with this package? Consider becoming a component owner.

[neilime]

Hi @blumamir, @dyladan, @[legendecas, @pichlermarc,

I will need you opinion on this PR.

I'm convinced that having instrumentation for just nestjs-core it to restrictive. Having an instrumation by nestjs package is bloated.

IMO the best solution is to deprecated the original nestjs-core instrumentation and forge a new nestjs (only) instrumentation.

I have made the code, it's working good, battle tested and backward compatible.

But I dont how to deal with de preciation and the new package. I've made what I supposed to be ok, but I'll appreciate your recommandation to mathc with repository practices.

Thanks

[david-luna]

Hi @neilime

Thanks for working on this. I'm okay with having a new and more generic instrumentation (let's wait for more feedback). IMHO I would split this PR into smaller ones with this order

• PR to add the new instrumentation (this one)
• wait for the publication of the new instrumentation
• PR to add the deprecation notice into @opentelemetry/instrumentation-nestjs-core
• PR to replace it in auto instrumentations
• after a period of time remove the deprecated instrumentation. Leaving a README for people looking at the instrumentation

@opentelemetry/instrumentation-fastify had a similar process. Ref: #2647

If you agree with this process I think this PR should only contain the new instrumentation. And I'd prefer to not refactor the current instrumentation so we avoid maintenance on it.