KAFKA-19895: Retry log cleaning after topic config updates

[arnabnandy7]

Summary

KAFKA-19895: This change allows log cleaning to recover without a broker restart after a partition has been marked as uncleanable.

When an unexpected exception occurs during cleaning, Kafka marks the affected partition as uncleanable and excludes it from subsequent compaction and deletion passes. This state is retained in memory, so updating the topic’s cleanup or retention configuration does not currently retry the partition. This can cause affected partitions, including __consumer_offsets partitions, to grow indefinitely until the broker is restarted.

Changes

• Clear the uncleanable state for a topic’s local partitions when its configuration is updated.
• Allow the log cleaner to retry those partitions after the underlying problem has been addressed.
• Preserve the uncleanable state of unrelated partitions.
• Document the uncleanable-bytes metric and recovery procedure.

Testing

Added unit coverage to verify that:

• Clearing one uncleanable partition does not affect other quarantined partitions.
• Updating a topic configuration clears the uncleanable state.

Tests commands:

./gradlew storage:test --tests org.apache.kafka.storage.internals.log.LogCleanerManagerTest
./gradlew storage:test --tests org.apache.kafka.storage.internals.log.LogManagerTest.testTopicConfigChangeRetriesUncleanablePartitions
./gradlew storage:checkstyleMain storage:checkstyleTest spotlessCheck

[github-actions]

A label of 'needs-attention' was automatically added to this PR in order to raise the
attention of the committers. Once this issue has been triaged, the triage label
should be removed to prevent this automation from happening again.