Update node-rdkafka to v3.2.0

[godber]

We should update to this:

https://github.com/Blizzard/node-rdkafka/releases/tag/v3.2.0

It in turn updates to librdkafka 2.6.0: Blizzard/node-rdkafka#1103

We should bump the minor version on our asset and make sure to update the terafoundation_kafka_connector version in the base image.

[godber]

On question we need to answer is how is this cooperative rebalance behavior triggered, then we need to test whether it works in our high-volume scenarios. I this these are clues:

• https://github.com/Blizzard/node-rdkafka/pull/1081/files#diff-e574f6617d5a1bd9fb35fab6b02e906b120024e0dcae87b010eed716e23820d4R312-R319
• https://kafka.apache.org/documentation/#consumerconfigs_partition.assignment.strategy
• https://github.com/confluentinc/librdkafka/blob/master/CONFIGURATION.md
  • Search for partition.assignment.strategy see below:

The name of one or more partition assignment strategies. The elected group leader will use a strategy supported by all members of the group to assign partitions to group members. If there is more than one eligible strategy, preference is determined by the order of this list (strategies earlier in the list have higher priority). Cooperative and non-cooperative (eager) strategies must not be mixed. Available strategies: range, roundrobin, cooperative-sticky.
Type: string

[busma13]

kafka_reader, kafka_sender, and kafka_dead_letter all have configs with a partition_assignment_strategy field. We will need to update the types to allow for cooperative-sticky. We will also need to update the schema.partition_assignment_strategy.format array for each.

Then we just need to update each operation in a job to set the partition_assignment_strategy if applicable.

[busma13]

partition_assignment_strategy should not be in the sender or dead_letter, so we will be removing them.
ref: #873