feat(microservices): expose transport server getter

[OlegStrokan]

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?

Currently INestMicroservice have no way to stop only the transport layer (port/connection) without triggering the full application shutdown lifecycle, when i call close() method from INestMicroservice stops the transport and triggers the full shutdown lifecycle - which is correct, but my business case is specific: the server has more then one grpc connection: control port (receiving commands), data port (for streaming data). when control sends a new TLS value the component needs to stop only the data port and restart it with new TLS value. Other port should remain active. but microservice.close() tears down everything because lifecycle hooks fire across entire di container

Issue Number: N/A

What is the new behavior?

Now we can stop listening on the transport layer, no lifecycle hooks, di side effects, so app stays alive
example of using:
await microservice.getTransportServer().close()
and of course old one:
await microservice().close() - still shut down everything

Does this PR introduce a breaking change?

• Yes
• No

Other information

i am not ai, i am a real person. the code was tested manually injecting updated nestjs into my infra + runnig tests.
i am aware of nestjs design - what microservice transport start once and die with the app, BUT i have unusual case where my application is a industrial adapter which needs process tls hot swap without shutdowning because there are another clients which depends on this application. I could probably bypass it using raw gprc lib, but i think it's better solution (also simple one)

i created ITransportServer to prevent circular deps between common and microservices packages. It's second version of my code implementation. In first one i just used "any" without adding new type, but later when i really injected new nest into my services it was inconvenient to use. I am open to discuss about different implementation

in the last commit i marked the abstract Server class as implements ITransportServer to
enforce the contract at compile time. ts structural typing already handle Server and ITransportServer compatibility , but without the explicit declaration a some new future changes to server.close() or server.listen() could silently break the interface guarantee withou compiler error at the source

[OlegStrokan]

Integration tests failed, but this looks like a flaky test to me.
I ran the failing test locally 10+times, and it passed every time.

a force push saves life

[coveralls]

Coverage Report for CI Build 0

Coverage decreased (-0.08%) to 89.907%

Details

• Coverage decreased (-0.08%) from the base build.
• Patch coverage: 1 of 1 lines across 1 file are fully covered (100%).
• 32 coverage regressions across 2 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

32 previously-covered lines in 2 files lost coverage.

File	Lines Losing Coverage	Coverage
packages/microservices/client/client-redis.ts	25	79.39%
packages/core/injector/instance-wrapper.ts	7	96.09%

---

Coverage Stats

Relevant Lines:	8580
Covered Lines:	7714
Line Coverage:	89.91%
Relevant Branches:	2929
Covered Branches:	2374
Branch Coverage:	81.05%
Branches in Coverage %:	No
Coverage Strength:	56.61 hits per line

---

💛 - Coveralls

[kamilmysliwiec]

could you please target v12.0.0 branch?

[OlegStrokan]

could you please target v12.0.0 branch?

done. the pipeline failed. I will check whether its related to my changes

EDIT: pipeline fixed

[OlegStrokan]

can someone review/approve this PR? It would be nice to have this feature in nest v12