test(idempotency): improve integration tests for utility

[dreamorosi]

Description of your changes

This PR introduces new integration tests for the idempotency utility, and improves the existing ones by expanding the test coverage and assertions.

The integration tests now include both function wrapper and Middy middleware, and across both test suites I have improved the test coverage by including tests for concurrent requests, Lambda timeouts, expired idempotency records, and different combinations of payload selection (dataIndexArgument) and filtering (JMESPath expressions).

Fixes for makeHandlerIdempotent middleware

While working on the unit tests for the Middy middleware I found out that due to the way the middleware was written, if customers configured more than one Lambda handler in the same file, some of the Idempotency settings would leak between handlers, for example, having a single file index.ts with two handlers like below:

export const handlerOne = middy(async (event, context) => {
  // do something
}).use(makeHandlerIdempotent({
  persitenceStore,
  configs,
});

export const handlerTwo = middy(async (event, context) => {
  // do something else
}).use(makeHandlerIdempotent({
  persitenceStore,
  configs,
});

Could result in the makeHandlerIdempotent overriding and sharing the persistenceStore and configs. Thanks to the integration tests we were able to catch this bug before releasing the utility.

The issue described above was fixed by moving the setup of these two objects in the before stage, and then storing references inside the Middy internal storage. In this way the objects are scoped to a specific request and can be accessed across stages of the same request.

Other changes

The PR also:

• updates the utility's README file to use the new name of the function wrapper (makeIdempotent) that was changed in a previous PR.
• updates the run-e2e-tests workflow so that the tests for this utility are run together with the others.

Related issues, RFCs

Issue number: closes #1555

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my change is effective and works
• The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

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

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[am29d]

❤️

[am29d]

LGTM