Redesign Completes<T> so it decouples composition and execution time

[kmruiz]

We realised after a long conversation that Completes<T> right now has an important issue that needs to be tackled: a Completes<T> pipeline can be run during the composition fase, because it runs potentially in different threads.

Our new proposal is to actually rework how Completes<T> works so it can be simplified, more efficient and easier to change. The design decisions that we want to take:

• Completes<T> composition will only be done in a single thread.
• Completes<T> execution will be lazy, it will be only run when there is an outcome and it's marked as ready.
• Completes<T> will be executed in a threadpool only if it's marked as ready and has an outcome.
• Completes<T> will separate two responsibilities: who is sending the outcome to the chain, and how the chain processes the outcome. For example, you can have a SingleSource<T> that will only emit a single outcome to the whole chain, and you can have also a RepeatableSource<T> that can emit up to N elements. We can build more sources from CompletableFuture<T> and other async components.
• Timeouts will act as gateways. We are not measuring the time we spend processing a step in the chain, but the deadline from an outcome to pass through the timeout gateway. So it will measure the time between outcomes.

Opinions and feedback are really appreciated.

It's also a good opportunity to work on the following issues and solve them:

• Support Completes<T> and CompletableFuture<T> In One Pipeline #15
• Support for composition of Completes #14
• Completes.recoverFrom() should support a handler that returns a Completes<Y> not just Y #13
• BasicCompletes Must Handle Latent Registration of recoverFrom(Exception) #12

[kmruiz]

@VaughnVernon I was thinking on composing operations, like we did on this closed PR that didn't work (because of multithreading): #11

[kmruiz]

Right now the new implementation requires the java property vlingo.InMemoryCompletes set to true to run. Any other value on this property (or keeping it empty) will run with BasicCompletes

[tjaskula]

@kmruiz @VaughnVernon is the new implementation working on Java or there are more tweaks to come ?

[VaughnVernon]

@tjaskula I think that the design itself is golden. The use of ready() greatly simplifies the overall design because there can be a single thread assigned to execution. It is possible that there will be some tweaks but I think the current design reflected here will remain:

https://github.com/vlingo/vlingo-common/tree/master/src/main/java/io/vlingo/common/completes

Other than the return type parameter for .NET you should be able to use this to great advantage :)

[VaughnVernon]

@kmruiz I have added andFinally() and andFinally(function). The knowhow is in the second overload. I assume I have implemented it correctly per the andFinallyConsume(consumer) implementation. I have tested this locally and it works fine. However, on vlingo-actors it hangs in the StageTest when querying the Directory for given actors by address. I think that this implementation is subject to predictive execution race conditions where countdowns are seen in dependent threads before the outcome state is set. The behavior I see is pretty typical of these kinds of inconsistencies. Although I much prefer the simplicity of this implementation is seems to require a considerable amount of additional testing to get it across the finish line. Unfortunately it will probably tend to fail on CI and machines other than the developer's.