fix: generation fails when schemas have an $Id field

[CameronRushton]

Problem
The generator generates file names using the $id value as its preferred option. This causes problems with code generation because the IDs typically contain unwanted characters that may change the path of the files or aren't allowed by the OS.
Since the x-schema-parser-id is what we tend to use to identify schemas and the name of the schema is either the parser ID or the json/yaml key of the schema, we would run into unnecessary confusion.
In short, when a schema with $id is present, the generator tries to name the file the $id value, which is identified by a different, independent x-schema-parser-id typically derived from a sometimes different key name.
We already prefer to use the x-schema-parser-id to identify schemas but sometimes use the key name to help, so the $id was causing us to not write the modelClass correctly.

Solution
The implemented fix is to remove the $id from the document before feeding it to the generator as part of the generate:before hook since $id isn't being used in the code generator anyway.

Theory
If $id would need to remain intact...
...the fix needs to be much more complicated. There are two big problems.

Problem 1: The code generator doesn't and shouldn't know how the generator names files. The implementation shouldn't matter, but since the generator favours naming files based on $id, it'll be common for the name to be manipulated to become valid. For example, changing 'http://example.com/something' to 'http-example.com-something'. In order to fix this in the generate:after hook, we need to know how the generator comes up with the names which smells bad.
This could also be a problem with the current naming strategy without $id, but it seems very unlikely.

Problem 2: Mismatch of x-schema-parser-id, the file name generated from $id, and the key name. There will be times when we need to translate the $id into the schema's x-schema-parser-id so that we know which schema we're talking about. We can do it early once, for now, but may to do it in other places later on.
For example...

validateSchemaName(schema, schemaName) {
	// The generator will say the name of the schema is the $id which is inconvenient for us.
	// In addition to making the className correct, we must make the key in the modelClassMap is easily known when we retrieve the modelClass. x-schema-parser-id is the best candidate key.
	if (schema.$id() == schemaName) {
		return schema.ext('x-parser-schema-id');
	}
	return schemaName;
}

Theoretical solution

• Change $id in generate:before to something file name friendly so the method is known to solve problem 1 and store the original $id value in another variable for use when needed.
• Use validateSchemaName() to translate use of $id to the x-schema-parser-id whenever we add/retrieve the schema to/from the map of schemaName: modelClass to solve problem 2.

Related issue(s)
Resolves #208

[CameronRushton]

This was moved into its own function just as a clean up

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
7.1% Duplication

[asyncapi-bot]

🎉 This PR is included in version 0.11.6 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀