Depends on CI step removal #11779

Motivation

The new Lambda Event Source Mapping (ESM) implementation v2 has been the default implementation since 3.8.0 and we announced the removal of ESM v1 with the next major release in the release notes.

Changes

• Remove config LAMBDA_EVENT_SOURCE_MAPPING and all dependencies
• Add LAMBDA_EVENT_SOURCE_MAPPING to deprecations
• Remove conditional deprecation for value of LAMBDA_EVENT_SOURCE_MAPPING
• Remove code localstack-core/localstack/services/lambda_/event_source_listeners
• Refactor utils used in ESM v2 → extract methods into ESM v2
  • from localstack.services.lambda_.event_source_listeners.utils import message_attributes_to_lower
  • from localstack.services.lambda_.event_source_listeners.utils import ( has_data_filter_criteria_parsed,)
• Deprecate and remove LAMBDA_SQS_EVENT_SOURCE_MAPPING_INTERVAL_SEC (we should have deprecated it earlier, but it's undocumented)

Testing

Mostly regression test suite.

Could check deprecation warnings manually.

TODO

What's left to do:

• Update Lambda v4 docs accordingly (near the release)

Discussion

• Should we consider switching the default event filter engine to Java (JPype-based)?
  • Pros
    • Perfect AWS parity for event filtering demonstrated by the test suite tests/aws/services/events/test_events_patterns.py (summary of different implementations in Add event matching test suite #10599)
  • Cons
    • Slower than Python-native (usually in the 10s on microseconds, but highly variable with spikes up to ~150-200ms)
    • Potential ext pipeline interaction with the siddy library used for Kinesisanalytics (same problem for EventBridge v2) and already monkeypatched ESM v2 tests
  • Dependency: The Python-based rule engine uses the same implementation as EventBridge v1