Disable nondeterministic IT (kroxylicious#3048)

Our dream was that we could guarantee that chained work is executed on
the filter dispatch executor. However in the empty case we complete
extremely quickly so there is a possibility that work chained on to
filterContext.topicNames(xyz) will execute in the calling thread, not
the filter dispatch thread.

We need to decide if we take things further, like implementing our own
CompletionStage with a different execution guarantee than
CompletableFuture. Or we could rely on javadoc to let developers know that
if they call topicNames from an uncontrolled thread, they will need to
switch back to the filterDispatchExecutor to mutate filter members
safely using a then*Async method of the CompletionStage.

Signed-off-by: Robert Young <[email protected]>

Author: robobario

kroxylicious-integration-tests/src/test/java/io/kroxylicious/proxy/FilterIT.java

@@ -37,6 +37,7 @@
 import org.apache.kafka.common.protocol.Errors;
 import org.apache.kafka.common.protocol.types.RawTaggedField;
 import org.apache.kafka.common.serialization.Serdes;
+import org.junit.jupiter.api.Disabled;
 import org.junit.jupiter.api.Test;
 import org.junit.jupiter.api.extension.ExtendWith;
 import org.junit.jupiter.params.ParameterizedTest;
@@ -130,6 +131,7 @@ void filtersCanLookUpEmptyTopicNames(KafkaCluster cluster) {
         }
     }
 
+    @Disabled("this test is non-deterministic, due to the nature of CompletableFuture, it is possible for the calling thread to execute the chained work")
     @Test
     void filtersCanLookUpEmptyTopicNamesInitiatedFromNonFilterDispatchThread(KafkaCluster cluster) {
         NamedFilterDefinition namedFilterDefinition = new NamedFilterDefinitionBuilder(TOPIC_ID_LOOKUP_FILTER_NAME,