KREST-2521 fixing consumer lag list failure

[ahuang98]

fix for https://confluentinc.atlassian.net/browse/KREST-2521
passing jenkins job - https://jenkins.confluent.io/job/Confluentinc%20Contributors/job/kafka-rest/job/PR-911/7/

[ahuang98]

confirmed we get the same test error from insufficient poll time
https://jenkins.confluent.io/job/Confluentinc%20Contributors/job/kafka-rest/job/PR-911/5/testReport/junit/io.confluent.kafkarest.integration.v3/ConsumerLagsResourceIntegrationTest/listConsumerLags_returnsConsumerLags/

java.lang.AssertionError: Failed after 2987 ms elapsed and 3 exponential backoff retries with 200 ms initial retry interval.
	at io.confluent.kafkarest.integration.v3.ConsumerLagsResourceIntegrationTest.listConsumerLags_returnsConsumerLags(ConsumerLagsResourceIntegrationTest.java:107)
Caused by: java.util.NoSuchElementException: No value present
	at io.confluent.kafkarest.integration.v3.ConsumerLagsResourceIntegrationTest.lambda$listConsumerLags_returnsConsumerLags$2(ConsumerLagsResourceIntegrationTest.java:128)
	at io.confluent.kafkarest.integration.v3.ConsumerLagsResourceIntegrationTest.listConsumerLags_returnsConsumerLags(ConsumerLagsResourceIntegrationTest.java:107)

[dimitarndimitrov]

I'm OK with the approach even if not ideal, but I have to wonder - unless this was failing in 100% of the cases (I don't think it was, although I might be wrong), is a single passing PR CI run a reliable validation for the fix? I can imagine how this can reduce the failure rate, but unless there's a qualitative change, I think we will be left in roughly the same spot that we were in.

In case this can be reproduced locally, I think we should check what is the failure rate from 100 runs before vs after.

• I think something like for i in {1..100}; do mvn -f kafka-rest/pom.xml -Dit.test= ConsumerLagsResourceIntegrationTest test-compile failsafe:integration-test >> ~/Downloads/KREST-2521.log; done should work, although that's in the not so common case where the failure can be reproduced locally...