build: add OpenAPI spec bundling, stop using URL references

[petermetz]

IMPORTANT: From now on, if you are changing the OpenAPI specification of any given
package within Cacti, please make sure to edit the template file instead of editing the
openapi.json specific file directly because changes in the openapi.json file will be
overwritten by the codegen script the next time you run it.
This slight alteration in the development flow is the least intrusive solution I could find
to resolving our issues with the release automation.

This change enables us to have our openapi.json files work without having remote and URL
references in them (which was a blocker issue for release automation).

1. The openapi.json files that we used to have are now called openapi.tpl.json where the
   tpl stands for template. Their content is equivalent to what openapi.json files used to
   have prior to this commit.
2. These template specs are fed into the bundler tool which then spits out the files which
   then are saved as openapi.json files. The big change is that these bundled versions are
   no longer containing any remote nor URL references, only local ones.
3. This means that we still get project-wide re-use of schema types from packages such as
   cactus-core-api, but we no longer suffer from the additional complexities of having to deal
   with remote and URL references.
4. The scirpt that performs the bundling is callable separately by executing this command

yarn tools:bundle-open-api-tpl-files

5. The yarn tools:bundle-open-api-tpl-files is also embedded as a warmup step of the
   larger codegen script so there is no need usually to call the bundling script separately.
6. The heavylifting in terms of bundling is done by the tooling script that can be found
   here: tools/bundle-open-api-tpl-files.ts. On a high level what it does is loop through
   existing openapi.tpl.json files throughout the project and then renders their bundled
   version next to it as openapi.json which then can be used by all of our tools as a self
   contained version of the template file which does still have the remote and URL references
   in it.

More information on what URL and remote references are can be read here on the official
OpenAPI website: https://swagger.io/docs/specification/using-ref/

Signed-off-by: Peter Somogyvari peter.somogyvari@accenture.com

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[jagpreetsinghsasan]

LGTM. The local references are much better in my opinion too

[petermetz]

@hyperledger/cacti-maintainers I've found a more efficient and less brittle way to do this type of vendoring automatically by way of this concept called bundling the open API specifications. It was originally a feature of the (now deprecated) swagger-cli tool, but the successor of it also implements it and it appears to work seamlessly based on my tests. I'll send an update to this pull request shortly with the refactored version which will be slightly less verbose but equivalent functinality.

[petermetz]

@hyperledger/cacti-maintainers I've pushed the latest changes and now this is once again ready for your review. I made sure to update the pull request description with the new changes, please re-read carefully!

[outSH]

@petermetz Looks great, sorry for late review. I've left few comment but none of them are critical, you can look into them in future PR or here if there's no rush :)