feat(microservices): add specific transport id to microservices

[maxbronnikov10]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

transportId field is hardcoded in specific server classes.
If users need more concurrency on same server or many servers need to extends from base server classes and override server id
Sample:

import { CustomTransportStrategy, KafkaOptions, ServerKafka } from '@nestjs/microservices';

export const NEW_KAFKA_TRANSPORT = Symbol('NEW_KAFKA_TRANSPORT');

export class NewKafkaServer extends ServerKafka implements CustomTransportStrategy {
  //@ts-expect-error In Nest.js ServerKafka can not override transportId
  transportId = NEW_KAFKA_TRANSPORT;

  constructor(config: KafkaOptions['options']) {
    super(config);
  }
}

Issue Number:
#14590
#11298

What is the new behavior?

Add new property to microservice options interface that overrides default transportId field in specific server classes

Does this PR introduce a breaking change?

• Yes
• No

Other information

[coveralls]

Pull Request Test Coverage Report for Build 509e49e5-e054-465a-bd3f-5172427e2355

Details

• 8 of 8 (100.0%) changed or added relevant lines in 8 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.002%) to 88.94%

---

Totals
Change from base Build 0ff12a80-22b7-43a2-8e8a-1d5a5d5d96fc:	0.002%
Covered Lines:	7197
Relevant Lines:	8092

---

💛 - Coveralls

[maxbronnikov10]

@kamilmysliwiec can u check this PR please?

[kamilmysliwiec]

instead of introducing a 2nd constructor parameter, wouldn't it be easier to expose a setter for the transportId attribute? And then set it only if the user passed a custom transportId (which won't be the case for 99% apps out there anyway)

[maxbronnikov10]

That would be easier, but another problem arises - what if the developer changes the transportId via setter at runtime and add handlers dynamically, which will cause unexpected errors because the current Server code doesn't have a status model like started or not_started.
So if you don't want to have a second parameter in the constructor because it will cause breaking changes for those extending the Server class - we need to make a status model or accept that risk and leave it to the developer's responsibility

I realize it's an unusual problem, but it should have been highlighted.

[kamilmysliwiec]

we can just leave a note on this in the docs

[maxbronnikov10]

done

[kamilmysliwiec]

LGTM