Kafka client metrics add second path for poll

[tbradellis]

The instrumentation module com.newrelic.instrumentation.kafka-clients-metrics-2.0.0 instruments KafkaConsumer#poll(Duration). This method is overloaded (KafkaConsumer#poll(long)) and both call a private method.

@meiao The private signature looks like it changed in 2.5.0 to use Timer instead of long.

https://github.com/apache/kafka/blob/ff4dff044a22ef0f3095c6f11c38a1a718ad7d13/clients/src/main/java/org/apache/kafka/clients/consumer/KafkaConsumer.java#L1217

Instead of creating a new module it looks like I could just instrument both public poll methods.
ConsumerRecords<K, V> poll(Duration timeout)
and
ConsumerRecords<K, V> poll(long timeoutMs)

verifyInstrumentation passes open ended for this from 2.0.0.
passesOnly 'org.apache.kafka:kafka-clients:[2.0.0,)'

Related Github Issue

#711

Testing

verifyInstrumentation passes open ended
passesOnly 'org.apache.kafka:kafka-clients:[2.0.0,)'

Alternatives

Instrument the private method, But will have to split into separate modules at 2.5.0 to cover the private method signature change.

[meiao]

We should not instrument this method as it is already instrumented in the 0.10.0.0 module.

[tbradellis]

@meiao I'm confused about what is needed here then, because if ConsumerRecords<K, V> poll(long timeoutMs)
is instrumented in 0.10 and ConsumerRecords<K, V> poll(long timeoutMs) is instrumented in 2.0.0 there should be coverage and no need to instrument the private ConsumerRecords<K, V> poll(final long timeoutMs, final boolean includeMetadataInTimeout).

I'm curious if the maybe the modules should all be refactored because of the weird overlap.

[meiao]

@tbradellis yes, we are all confused.
The first description of the ticket was made on the assumption that the 2.0.0 module was a standalone module, which turned out to not be true.

Also at that point, it was also believed that the 2.0.0 module would instrument Kafka 3.0.0, since the verifyInstrumentation was open ended. Even though 2.0.0 does apply to 3.0.0, it is not enough by itself, since it is not a standalone module.

So we should revisit the internal ticket that led to open this ticket and see if their problem was in 2.x or 3.x.
If it was 3.x, there is likely no gap in 2.x, but we do need to fully instrument 3.x.