Potential context leak in kafka-clients instrumentation

TracingIterator wraps Iterator<ConsumerRecord> returned from kafka, and starts scopes in next() and closes them in hasNext() for each record in the iterator.

This is a clever way to put the context in scope, and may be acceptable, but worth reviewing alternatives, including removing it and only automatically putting context in scope when kafka is used from higher-level APIs, e.g. spring-kafka's MessageListener.onMessage() and vertx-kafka's KafkaReadStream.poll() which takes a handler (we can start a span for the handler and create links to all of the messages in the batch).

Start by reviewing TracingIterator and how it wraps the Kafka Iterator, focusing on the scope lifecycle across next() and hasNext(). Then compare the suggested higher-level entry points, spring-kafka's MessageListener.onMessage() and vertx-kafka's KafkaReadStream.poll(). Done requires an agreed approach for avoiding context leaks; the issue does not specify one.