Maintenance: introduce nox to test optional dependencies

[heitorlessa]

Why is this needed?

Today's release suffered a regression due to static typing accidentally requiring an optional dependency for customers.

We must not make any release until we have a safeguard to prevent this in the future.

#4498

Update with task list - 14/06

• Maintenance: Install and configure nox #4519
• Maintenance: add the Logger feature to nox tests #4520
• Maintenance: add the Metrics feature to nox tests #4521
• Maintenance: add the Tracer feature to nox tests #4522
• Maintenance: add the Event Handler feature to nox tests #4523
• Maintenance: add the Parameters feature to nox tests #4553
• Maintenance: add the Batch Processing feature to nox tests #4562
• Maintenance: add the Typing feature to nox tests #4554
• Maintenance: add the Validation feature to nox tests #4555
• Maintenance: add the Event Source Data Class feature to nox tests #4561
• Maintenance: add the Parser feature to nox tests #4556
• Maintenance: add the Idempotency feature to nox tests #4560
• Maintenance: add the Feature Flags feature to nox tests #4557
• Maintenance: add the Streaming feature to nox tests #4558
• Maintenance: add the Middleware Factory feature to nox tests #4559
• Maintenance: add the Data Masking feature to nox tests #4573

Which area does this relate to?

No response

Solution

Use nox, or create new workflows where we test bare dependencies, and every optional dependencies.

Acknowledgment

• This request meets Powertools for AWS Lambda (Python) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Java, TypeScript, and .NET

[leandrodamascena]

Assigning to me.

[leandrodamascena]

Introducing nox requires a lot of changes to our tests and can easily become a PR with hundreds of lines of changes. So I'll break this down into small PRs to make reviewing easier.