fix(parser): set etag optional for delete object notifications

[am29d]

Description of your changes

In this PR we set etag to optional. We initially discussed in #2410 that it'd be best to split s3 event notification schema into separate objects for event types (delete, create, update, lifecycle, etc) similar to how @types/aws-lambda does it.

However @types/aws-lambda is not correct for the s3 notification, i.e. etag is a required field in DeleteObject events, thus we can't rely on them. In addition, splitting the event types would introduce either redundancy between the events of the common fields, or additional complexity if we decide to split them based on base and specific fields. It'd be hard to read them.

Related issues, RFCs

Issue number: closes #2410

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]

I thought we discussed that we'd break up the schemas into separate ones for each S3 event notification, why the change?

[dreamorosi]

Just saw your comment under the issue, would have been useful to have it as part of the PR body.

---

It would really be helpful, and also set an example for external contributor, if we maintainers took time to write informative descriptions so that the PR are self-contained and can be evaluated as standalone.

Having a "fixes #nnn" doesn't necessarily explain the choices made, and when we go back to the PRs at release or after some time we might not know immediately the why and what behind the change.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud