KAFKA-18644: improve generic type names for internal FK-join classes

[mjsax]

Naming of generic types is not consistent, and hard to read. Standardizing to use KLeft/VLeft for the left/primary table, and KRight/VRight for right/foreign table, and using VOut as join result type.

[mjsax]

Small refactoring proposed by IntelliJ -- guess it make sense to extract into a helper method -- easier to read overall, as semantics are a little clearer.

[mjsax]

Suppression some IntellIj warnings about "potential resource leaks" for not using try-with-resource for the "Closable" Serdes we get.

Similar elsewhere.

[mjsax]

Java 17:

FAILED ❌ CooperativeConsumerCoordinatorTest > testOutdatedCoordinatorAssignment()
FAILED ❌ SharePartitionManagerTest > testReplicaManagerFetchShouldProceed()
FAILED ❌ SharePartitionManagerTest > testDelayedInitializationShouldCompleteFetchRequest()
FAILED ❌ RemoteIndexCacheTest > testIndexFileAlreadyExistOnDiskButNotInCache()
Found 3 flaky test failures:
FLAKY ⚠️  KafkaShareConsumerTest > testVerifyFetchAndAcknowledgeSync()
FLAKY ⚠️  AbstractCoordinatorTest > testWakeupAfterSyncGroupReceivedExternalCompletion()
FLAKY ⚠️  StickyAssignorTest > testLargeAssignmentAndGroupWithNonEqualSubscription(boolean).hasConsumerRack = false

Java 23:

Found 3 test failures:
FAILED ❌ SharePartitionManagerTest > testReplicaManagerFetchShouldProceed()
FAILED ❌ SharePartitionManagerTest > testDelayedInitializationShouldCompleteFetchRequest()
FAILED ❌ MetricsDuringTopicCreationDeletionTest > "testMetricsDuringTopicCreateDelete(String).quorum=kraft"
Found 1 flaky test failures:
FLAKY ⚠️  StickyAssignorTest > testLargeAssignmentAndGroupWithNonEqualSubscription(boolean).hasConsumerRack = false

[lucasbru]

LGTM, just one comment for your consideration.

[lucasbru]

It's a bit weird that right is left and left is right. But not sure if I have a solution as we cannot swap them. How about standardizing on KForeign and KPrimary? That seemed rather clear to me, but I may be lacking context.

[mjsax]

The order is on-purpose, because that is the actually order of both arguments of CombinedKey, ie, especially how we serialize it (but also constructor argument order; and the constructor argument order is also the way it is, to express the serialization order), what is important as we apply range-scans on RocksDB using the combined-key. I was also first thinking about maybe swapping it, but in the end, I did keep as is, because it might be better to align the order?

About the names. I did the change on-purpose, because the variable names, already have good names, it it IMHO make it's very clear?

    private final KRight foreignKey;
    private final KLeft primaryKey;

plus:

CombinedKey(final KRight foreignKey, final KLeft primaryKey)