fix(): support multiple GraphQLModule in an app

[wtho]

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
• Docs have been added / updated Docs were already formulated as if this bug didn't exist

PR Type

What kind of change does this PR introduce?

[X] Bugfix

What is the current behavior?

Currently, when wanting to use multiple GraphQLModules (different schemas for separate endpoints) in combination with the code-first approach, there will be an error such as Error: Schema must contain uniquely named types but contains multiple types named "User"..

Issue Number: #721

What is the new behavior?

Now it works.
During GraphQLModule initialization, basically all storages are cleared and the codebase is re-scanned from scratch including re-evaluation of annotations. Only the TypeDefinitionsStorage is an exception, which keeps references to outdated objects using the maps InputTypeDefinitionsLinks and outputTypeDefinitionsLinks.

With the new behavior, these storages are cleared as well in the GraphQLSchemaFactory during GraphQLModule initialization.

Does this PR introduce a breaking change?

[ ] Yes
[X] No

Other information

I opted to keep code changes minimal while fixing the bug. This means I mixed static method calls with intance method calls in the GraphQLSchemaFactory and extended an existing test to mimic the problem. If you want me to add an additional test or structure the code differently, just let me know.
Same goes for a Changelog or docs, so far I haven't touched any.

Closes #721

[kamilmysliwiec]

Unfortunately, this is just a workaround that won't make it possible to have multiple separate apps with the code first approach. Although it may let you start your application, the final result won't be correct.

The only way to solve this issue (multiple separate endpoints) is to introduce a new feature that lets you associate types (e.g., object types) with NestJS modules, for example, using the following construction @ObjectType({ registerIn: CatsModule }). In this case, types wouldn't be global anymore and we could store them per app instead of a per process, but I don't quite busy atm and I won't have enough time to implement that. I hope to look into that in the near future, but I cannot promise anything.

[wtho]

I see.

Personally I don't mind global types, there are use cases where one might want to have the same types as in another module and just one additional mutation. I think just assigning each type to one module only might solve only a part of the problem.

Why does each module have to trigger a rescan on the whole codebase? Can't we just reuse the storages? This would also reduce startup time for these use cases.

[nick4fake]

@kamilmysliwiec it still fully covers case that @wtho has mentioned. Looking on the original issue thread (#721) almost every person wants exactly this. Could you please merge this PR? While approach that you want to implement in future is not covered it still closes very annoying blocking bug.