KAFKA-20860: Retry consumer reconciliation after synchronous failure

[lh0156]

Summary

• Reset the reconciliation-in-progress latch when synchronous reconciliation setup fails.
• Handle synchronous failures while starting revocation and assignment without breaking the consumer background loop.
• Add regression coverage proving the next reconciliation loop retries successfully.

Motivation

A RuntimeException thrown after reconciliation starts but before its asynchronous future chain is established can leave the membership manager permanently stuck because reconciliationInProgress remains true. This change treats that setup failure as a failed attempt, preserves the existing auto-commit failure behavior, and allows the next poll to retry.

Testing

• ./gradlew :clients:test --tests org.apache.kafka.clients.consumer.internals.ConsumerMembershipManagerTest
• ./gradlew :clients:test --tests org.apache.kafka.clients.consumer.internals.ConsumerMembershipManagerTest --tests org.apache.kafka.clients.consumer.internals.StreamsMembershipManagerTest --tests org.apache.kafka.clients.consumer.internals.ShareMembershipManagerTest
• ./gradlew :clients:check --no-build-cache --console=plain

Fixes KAFKA-20860

Reviewers: Lianet Magrans lmagrans@confluent.io

[lianetm]

Thanks for looking into this @lh0156 ! I left a comment in jira mentioning how I don't see how this could be reachable. Am I missing a case where we could indeed have such "sync failure" in that section of the code? Or was the motivation here just to be defensive?