Event streaming shouldn't be limited to the number of threads in executor service

[cardil]

As discussed #11 (comment) the current implementation is limited to the number of threads in the executor service.

showcase/quarkus/src/main/java/com/redhat/openshift/knative/showcase/events/EventStore.java

Lines 17 to 27 in a01a18c

	private final ExecutorService executorService =
	Executors.newFixedThreadPool(12);
	Multi<CloudEvent> stream() {
	var p = new EventsPuller();
	return Multi.createBy()
	.repeating()
	.supplier(p::pull)
	.indefinitely()
	.runSubscriptionOn(executorService);
	}

It should be possible to rewrite it to better solution, which either:

• Make an 'artificial' stream that emits a 'heartbeat' every 25ms and only then wakes up, looks at events and goes to sleep. That should handle any number of calls on a single thread
• Use a different implementation of events that is event-driven, that is, it tells you when something appears in it. Maybe using MultiCreate#emitter(java.util.function.Consumer) is a good idea. We can use a factory like this and just call emit on it as we get the next event. The stream emits nothing, and everything non-blocking sleeps.