KAFKA-20733: Fix fetchResponseWithUnexpectedPartitionIsIgnored passing for wrong reason with CONSUMER protocol

[david-parkk]

Summary

KafkaConsumerTest.fetchResponseWithUnexpectedPartitionIsIgnored was
annotated with @EnumSource(GroupProtocol.class), but the CONSUMER
protocol case passed for the wrong reason.

The CONSUMER protocol uses FetchRequestManager and relies on
ConsumerGroupHeartbeat for rebalancing. Since the test does not set up
heartbeat-based rebalancing, partition assignment never completes and 0
records are returned — not because FetchSessionHandler correctly
rejected the response.

Analysis

While writing the CONSUMER protocol test, we first attempted to use
AsyncKafkaConsumerTest as a reference. However, it was not suitable
because fetchCollector is replaced with a Mock, meaning
FetchSessionHandler's actual rejection logic is never exercised.

We also found that naively adding the CONSUMER case to
KafkaConsumerTest does not work either. The test uses
prepareResponse() for the Join and Sync group requests, but these
responses were never consumed — because the CONSUMER protocol does not
go through the classic Join/Sync rebalance flow. As a result, the fetch
phase was never reached. FetchRequestManagerTest is the correct
location for this test, as it directly runs FetchSessionHandler
without mocking.

Changes

• KafkaConsumerTest: Restrict
  fetchResponseWithUnexpectedPartitionIsIgnored to CLASSIC protocol
  only, where the existing setup correctly exercises
  FetchSessionHandler's unexpected partition rejection logic.

• FetchRequestManagerTest: Add
  testFetchResponseWithUnexpectedPartitionIsIgnored to properly cover
  the CONSUMER protocol path. The test verifies that when a
  FetchResponse contains a partition not included in the FetchRequest,
  FetchSessionHandler rejects the entire response and no records are
  returned to the consumer.

• +KafkaConsumerTest: Rename
  fetchResponseWithUnexpectedPartitionIsIgnoredto
  testFetchResponseWithUnexpectedPartitionIsIgnored to align with the
  existing test naming convention in the class.

Reviewers: Lianet Magrans lmagrans@confluent.io

I'm happy to make any adjustments based on your feedback. Thank you to
the maintainers for taking the time to review this contribution!

[lianetm]

Thanks! Just a nit

[lianetm]

could you please add a comment here that CONSUMER is tested separately (just to avoid confusion, it's not that the asyncConsumer does not support this)

[david-parkk]

@lianetm Thanks for the review!
I've addressed your feedback — could you take another look when you get a chance?