Maintenance: Refactor Feature Flags

[heitorlessa]

Summary

Stream of consciousness tasks

• Split feature flags functional tests into unit and functional
• Make Schema Validation errors more granular (backwards compatible!) to decouple tests (match="...")
• Review areas where we can make testing easier to author and less error-prone
• Identify slowest areas that contribute to tests being the slowest in our test suites (e.g., we're unnecessarily creating a dict of anonymous lambda fns)

Why is this needed?

Feature flags tests are dubious in value and we tend to find newer bugs that are easily preventable - see #2058. We haven't invested much in refactoring feature flags since the early days, and rushed to launch for various reasons.

We need to pay tech debt and make it more robust, and more easily extensible (future bring-your-own-conditions of sorts, new Storage Layer).

Which area does this relate to?

Feature flags

Solution

No response

Acknowledgment

• This request meets Lambda Powertools Tenets
• Should this be considered in other Lambda Powertools languages? i.e. Java, TypeScript

[anafalcao]

Closing as not planned for now