fix: Fix kinesis_target and kinesis_parameters dynamic blocks

[mschuwalow]

Description

Reopened #91 as the issue is still present.

Motivation and Context

Target

Before this change the target configuration for kinesis partition seems to be intended to look like this:

kinesis_target = {
  partition_key_path = “$.id”
}

Actually planning with this configuration present will error out though. Reason for this is that the for_each will assign the iterator to just [true] and subsequently try to access a field on it:

│ Error: Invalid function argument
│ 
│   on ../../main.tf line 200, in resource "aws_cloudwatch_event_target" "this":
│  200:       partition_key_path = lookup(kinesis_target.value, "partition_key_path", null)
│     ├────────────────
│     │ kinesis_target.value is true
│ 
│ Invalid value for "inputMap" parameter: lookup() requires a map as the first argument.

After this change the configuration looks like this and works as intended (see examples):

partition_key_path = "$.id"

Schedule

Before this change the target configuration for kinesis partition key seems to be intended to look like this:

kinesis_parameters = {
  partition_key = “foo”
}

Actually planning with this configuration present will error out though.
Reason for this is the the schedule input would no longer be a valid map due to inconsistent types:

│ The given value is not suitable for module.eventbridge.var.schedules declared at ../../variables.tf:177,1-21: attribute types must all match for conversion
│ to map.

Additionally even if it passed the for_each will assign the iterator to just [true] and subsequently try to access a field on it --- failing either way.

After this change the configuration looks like this and works as intended (see examples):

partition_key  = "foo"

Breaking Changes

No, as the functionality was not working in the first place.

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects

• I have executed pre-commit run -a on my pull request

[github-actions]

This PR has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this PR will be closed in 10 days

[github-actions]

This PR was automatically closed because of stale in 10 days

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.