Improve validation of lambda concurrency settings #6874
Description
User Story
As a user deploying Sleeper, I want to know straight away when I set a configuration that is not deployable, so that I don't have to wait for it to deploy and roll back before I can fix my problem.
Description / Background
If you set sleeper.statestore.committer.concurrency.reserved to a value lower than sleeper.default.lambda.concurrency.max or sleeper.statestore.committer.concurrency.max, the CDK deployment will fail because it refuses to set the maximum concurrency greater than the reserved concurrency. It waits until it tries to deploy the lambda before failing, then rolls back the whole deployment.
We'd like to review the setup of our lambda concurrency configuration properties, and ensure that they're validated correctly and any relationships between them are clear in the documentation.
Technical Notes / Implementation Details
This can be tested in InstancePropertiesTest.
We currently have some validation behaviour comparing different properties in InstanceProperties.validate, but it looks like if those properties are not readable it will throw an exception instead of failing validation.
We could add some structure around this to allow it to record the failure and move on to other validation criteria, instead of throwing an exception all the way out. This could be similar to the setup we have for validation properties. In that case we use validation predicates on each property, but for this we could have another set of validation predicates for the properties object as a whole.