Enhance parity for DynamoDB to Kinesis stream integration

[whummer]

Motivation

Following a customer request, it seems that our integration between DynamoDB tables and Kinesis streams is not fully working for certain DDB operations, in particular when using the transact_write_items operation. (Apparently it worked for older versions prior to 3.0, but I haven't confirmed).

🚧 At this point, the PR only adds a snapshot test to illustrate the behavior - proper logic still needs to be implemented. (may need some help from service owners here, if possible 🙌 )

Wondering if this TODO comment could be related (as I know @bentsku has been working on some pretty significant performance enhancements recently 🚀 ):

localstack/localstack/services/dynamodb/provider.py

Line 1112 in 45d39ed

# TODO: refactor to apply the same logic as in `BatchWriteItem`: don't prep records if not stream enabled

Update: After discussing with @bentsku , the TODO above is not related - the fix was essentially related to converting a table ARN to the table name.

Changes

• enhance logic in has_streams_enabled(..) to extract the table name from incoming table ARN
• fix attributes in forwarded records, for better parity
• add a de_dynamize_record util function and refactor dynamize_value to use boto TypeSerializer utils
• add a test_enable_kinesis_streaming_destination snapshot test to cover the functionality

[whummer]

Moving this test to a new test_dynamodb_streams.py file (only refactoring, no functional changes)..

[github-actions]

LocalStack Community integration with Pro

    2 files      2 suites   1h 21m 21s ⏱️
2 616 tests 2 367 ✅ 249 💤 0 ❌
2 618 runs  2 367 ✅ 251 💤 0 ❌

Results for commit 66b875a.

♻️ This comment has been updated with latest results.

[bentsku]

I can add a comment related to the comment: for BatchWriteItem, we always prepped the records as if they would be sent down to a stream, which took time. I've refactored BatchWriteItem as it was the affected operation at the time, and introduced logic to not prep records if no streams were attached to the targeted tables.

The comment was the only change in TransactWriteItems, so I'm not aware of anything that would have broken it. I think the only changes around 3.0 were multi accounts and the performance work. I hope I did not break anything with unrelated changes, but as the other operations still "stream", I suppose it could be a minor issue.

Refactoring TransactWriteItems to follow the same kind of model as BatchWriteItems would be good I think, and a first step in trying to fix the issue.

[coveralls]

coverage: 83.793% (-0.03%) from 83.825%
when pulling 66b875a on ddb-kinesis-stream
into 45d39ed on master.

[whummer]

@bentsku Kudos for fixing the tests and pushing the PR over the line! 🚀 I cannot approve my own PR, but LGTM! :)

[giograno]

🚀

[bentsku]

I'll also approve my own work 😄 the -ext pipeline is also all green for this PR!
Also, thanks @whummer for updating the PR description with my changes as well. Nice to see boto made it much cleaner about the dynamize util function, we also have some unit tests for it and they are still passing!