fix(@nestjs/graphql): need to properly close websocket servers

[jkossis]

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, we do not properly shutdown the websocket transports (graphql-ws & subscriptions-transport-ws).

It looks like there was some logic removed here (bottom of the graphql-ws-subscription.service.ts diff) that mimics graphql-ws's tear-down logic. And that the net new logic from that diff dupe'd this same behavior (just sending a 1001) for tearing down subscriptions-transport-ws, which doesn't seem reflective of what ApolloServer was doing when they called .close() (back in V2) on the now-deprecated subscriptions-transport-ws's close handler.

I noticed the behavior when my client was receiving the manually sent 1001, but was still able to immediately reconnect. This led me to discovering that we were just sending that code without doing anything else beyond that. I have async tear-down logic in my own OnModuleDestroy's, so the client being able to reconnect and request resources that I was actively trying to tear-down led to the discovery of these issues.

What is the new behavior?

All this to say, I think it makes the most sense to defer the tear-down logic to the libraries/protocols themselves. I am very much open to feedback and discussion on this 👍🏻.

Does this PR introduce a breaking change?

If folks were relying on the server not being properly shut down, then maybe? My gut says no, but interested in what others think.

• Yes
• No
• Maybe

Other information

[jkossis]

@kamilmysliwiec, obviously wanna get your thoughts on this.

[kamilmysliwiec]

LGTM