fix: Proper handling of clashing types case

[candiduslynx]

Instead of #107

This PR aims to properly reference situations when different types (either shadowed ones or originating different packages, but having the same name) are referenced incorrectly (specifically, only the 1st entry is properly handled, other encounters of the same type name blindly reference the 1st definition, even if the types aren't the same).

To achieve this, the following changes were made:

1. An internal _type field was added to jsonschema.Schema struct
2. When adding new definition to the jsonschema.Schema.Definitions map, original reflect.Type value is stored in _type field
3. When considering a definition to be referenced, no only the type name is taken into account, but also:
   1. package name
   2. whether the types can be assigned to each other
4. If an entry isn't found by the name originally suggested (either inferred from type name, or from jsonschema.Reflector.Namer result), the code will try to locate a proper entry by adding -idx (e.g., -1, -2, etc.) suffix to the name value

[candiduslynx]

@samlown I propose this short change instead of an extra option from #107 (it will allow to reference all unique types still, but no JSON pointers logic is required so no need to rely on the validation implementation to support that).

[candiduslynx]

this is required for shadowing case, see TestShadowedClashingTypes

[candiduslynx]

@samlown I hope you're doing well in these uneasy days.

I've implemented the changes in #109 & #110 & tested them via a fork at github.com/cloudquery/jsonschema@cqmain.

The results of using the updated code along with NullableFromType: true, RequiredFromJSONSchemaTags: true is something I'm quite satisfied with.
You can find an example in schema.json file. It includes both the nullable properties based on the field type & the clashing types (you can easily find them searching for -1" suffix)).

Could you please give an estimate when these PRs (#109 & #110) could be merged? It'll be far easier to pin an upstream version instead of maintaining a fork for these 2 changes.

[candiduslynx]

Hi @samlown!
Is there a chance to get this reviewed along with:

• feat: Add NullableFromType option #110
• fix: Don't limit the explicit format #111
• fix: Key construction in ExtractGoComments #112

[candiduslynx]

Hi @samlown! Is there a chance to get this reviewed along with:

• feat: Add NullableFromType option #110
• fix: Don't limit the explicit format #111
• fix: Key construction in ExtractGoComments #112

Hi @samlown!
Could I have any ETA here?