Added API signature validation

[BarcoMasile]

Description

Added API input validation mechanism + decorator to validate API invocation at the controller level.

Changes

• added Marshmallow dependency to requirements.txt
• implemented new error handler for validation errors
• implemented validation mechanism + decorator
• provided three schemas with additional validation and adopted the new decorator on their respective endpoints
• added tests for all new code

How Has This Been Tested?

• unit tests
• e2e tests
• manually
• postman

References

PR Quality Checklist

• [x] I added tests to new or existing code
• [ ] I removed hardcoded strings and used our i18n solution instead (see here)
• [ ] I made sure no sensitive info gets logged at any time in the codebase (see here) (e.g. no user info or details, no stacktraces, etc.)
• [x] I checked that infrastructure/update_infrastructure.sh runs without any error
• [x] I checked that npm run build builds without any error
• [x] I checked that clusters are listed correctly
• [x] I checked that a new cluster can be created (config is produced and dry run passes)
• [x] I checked that login and logout work as expected

In order to increase the likelihood of your contribution being accepted, please make sure you have read both the Contributing Guidelines and the Project Guidelines

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[mendaomn]

General questions: how is the text of the error messages generated? It's not a concern for this PR, but I'm wondering:

• can they be centralized, or otherwise searched through in case we ever needed to spot a specific issue starting from the error message? (e.g. we find the error message, and we need to get to the schema definition to see if there is a bug)
• can they be internationalised, or customized at all?

[BarcoMasile]

General questions: how is the text of the error messages generated? It's not a concern for this PR, but I'm wondering:

• can they be centralized, or otherwise searched through in case we ever needed to spot a specific issue starting from the error message? (e.g. we find the error message, and we need to get to the schema definition to see if there is a bug)
• can they be internationalised, or customized at all?

The library of choice allows for customization of error message at the field level so we can (in the future) for example return i18n keys to the frontend and let the frontend translate those for the users @mendaomn

[mendaomn]

General questions: how is the text of the error messages generated? It's not a concern for this PR, but I'm wondering:

• can they be centralized, or otherwise searched through in case we ever needed to spot a specific issue starting from the error message? (e.g. we find the error message, and we need to get to the schema definition to see if there is a bug)
• can they be internationalised, or customized at all?

The library of choice allows for customization of error message at the field level so we can (in the future) for example return i18n keys to the frontend and let the frontend translate those for the users @mendaomn

Good, I noticed you added the request.path in the ValidationError constructor. Thus, we should be able to easily traceback to the failing schema in case of validation errors. Good job!