feat(idempotency): preserve original error when wrapping into IdempotencyPersistenceLayerError

[am29d]

Description of your changes

We use IdempotencyPersistenceLayerError to handle any unknown error that might occur during persistent operations. Examples are IAM permissions, connections, or other configuration issues. Therefore, we need to preserve the original error, so the developer can understand the cause.

With this PR we introduce a cause that enriches the original error.

I have also renamed the error file to align with the recent refactoring of the parameter utility.

Related issues, RFCs

Issue number: closes #1530

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.

[dreamorosi]

Should we add the same cause related logic to the before, after, and onError phases of the middleware?

[am29d]

Agh, good catch!

[dreamorosi]

Nicely done, I never thought we could add cause like this!

I left one question about whether or not we should add the same cause to the middy middleware.

Also I think sometime soon in a separate PR we should look into whether we can support #1361, I tried to print one of the errors with cause (logger.error('An error occurred', err);) thrown by us in this build and the cause doesn't show anywhere - I think we should support it if possible.

[am29d]

Nicely done, I never thought we could add cause like this!

The implementation is naive and since we did not have anything before, I am also open for discussion on alternatives.

Also I think sometime soon in a separate PR we should look into whether we can support #1361, I tried to print one of the errors with cause (logger.error('An error occurred', err);) thrown by us in this build and the cause doesn't show anywhere - I think we should support it if possible.

I can look into that in a separate PR.

[dreamorosi]

LGTM!