importer-rest-api-specs - parse orphaned discriminated models in nested files

[stephybun]

This PR closes #3693 and is related to #2551 but doesn't close it since we skip over this new functionality for DataFactory due to #3725.

Although we iterate over files in a nested directory structure, if the files have no paths defined then we don't parse any of the models defined in them.

This change adds the following functionality:

• Will find all discriminated models in files without any paths
• Find any models that the discriminated models reference
• Combine them into the resource they belong to (this depends on the file name, ChaosStudio and DataFactory use the resource name as the file name)
• Links the discriminated models to the parent, updating the data on the model that describes it as a discriminator

Note: DataMigration and SecurityInsights are also affected by this change. DataMigration results in the addition of a lot of new "resources" due to the naming of the files, we may want to consider skipping this functionality for DataMigration as well.

[tombuildsstuff]

hey @stephybun

Thanks for this PR - I've taken a look through and left a few minor comments inline, but on the whole this is looking pretty good, if we can fix those up then this should otherwise be good to merge 👍

Thanks!

[tombuildsstuff]

Given that the structure of Azure/azure-rest-api-specs has changed multiple times in the past - I suspect we probably shouldn't assume that only Constants and Models are present within the nested directories (even if that's the case today).

Whilst we're merging the result of this function in combineResourcesWith - rather than assuming the Swagger Tag is unique within this function (as we're doing here by writing to resourcesOut without checking for an existing value) - I suspect it'd be worth supporting merging into resourcesOut, as we do above (similar to lines 52-57 above) so that we don't unintentionally overwrite any Operations/Resource IDs which may be defined for an existing Tag, should Operations be added into a nested directory?

Alternatively we could look to surface an error here if the Swagger Tag already exists within resourcesOut - but since we'd end up needing to implement the merge to fix that error, I suspect it'd be worth supporting merge from the start for consistency with the rest of the function?

[stephybun]

Although I'm not in agreement that it's necessary I've added the logic to merge the resource information for a tag if it already exists since there isn't any harm in adding it.

Because this function is called on a per file basis, if any tags or operations were defined in the file it would be pulled out either here

pandora/tools/importer-rest-api-specs/components/parser/parser.go

Line 24 in 793c3e5

resource, err := d.parseResourcesWithinSwaggerTag(&tag, resourceProvider, resourceIds)

or here

pandora/tools/importer-rest-api-specs/components/parser/parser.go

Lines 37 to 39 in 793c3e5

	// however some things don't, so we then need to iterate over any without them
	if _, shouldIgnore := tagsToIgnore[strings.ToLower(serviceName)]; !shouldIgnore {
	resource, err := d.parseResourcesWithinSwaggerTag(nil, resourceProvider, resourceIds)

resulting in a populated resources variable which means we would never enter this part of the function and no prior tags could exist if we ended up here.