feat(cf): Improve syntax in CompletableFuture

[jabrena]

Features added:

• Better usage of Completable future moving to a non-blocking syntax.
• Http Client use HTTP 1.1 to not share anything in compare to HTTP 2. Now HttpClient use Executor Service
• Solution implement autocloseable
• Value became ScenarioResult (Better naming).
• Better helper methods to be used in the different scenarios
• Use modules to import classes

[jabrena]

In the process to improve current Solution based on CompletableFuture, using a non blocking approach, I had to understand better the relation between JDK and OS details:

+----------------------------------------------------------+
|                   Your Java application                  |
|   HttpClient.sendAsync()  CompletableFuture  Virtual     |
|                           threads                        |
+---------------------------+------------------------------+
                            |
                     Java API calls
                            |
                            v
+----------------------------------------------------------+
|                      JDK internals                       |
|                                                          |
|  +----------------+  +----------------+  +------------+  |
|  |   HttpClient   |  |Completable     |  | NIO        |  |
|  | java.net.http  |  |Future          |  | Selector   |  |
|  | HTTP/1.1 HTTP/2|  |thenApply       |  | java.nio   |  |
|  +----------------+  |thenCompose     |  | .channels  |  |
|                      +----------------+  +------------+  |
|                                                          |
|  +----------------------------------------------------+  |
|  |             Native I/O layer (JVM / JNI)           |  |
|  |  EPollSelectorImpl   KQueueSelectorImpl            |  |
|  |  IOURingSelectorImpl                               |  |
|  |  wraps OS primitives into Java Selector API        |  |
|  +----------------------------------------------------+  |
+---------------------------+------------------------------+
                            |
                         syscalls
                            |
                            v
+----------------------------------------------------------+
|          Kernel -- I/O event notification layer          |
|                                                          |
|  +----------------+  +---------------+  +------------+   |
|  |     epoll      |  |    kqueue     |  |  io_uring  |   |
|  | (Linux only)   |  | (macOS/BSD)   |  | (Linux 5.1+|   |
|  |                |  |               |  |            |   |
|  | epoll_create1()|  | kqueue()      |  | io_uring   |   |
|  | epoll_ctl()    |  | kevent()      |  | _setup()   |   |
|  | epoll_wait()   |  | kevent() wait |  | SQ/CQ ring |   |
|  |                |  |               |  | zero-copy  |   |
|  +----------------+  +---------------+  +------------+   |
+---------------------------+------------------------------+
                            |
                          watches
                            |
                            v
+----------------------------------------------------------+
|                  Device drivers & VFS                    |
|                                                          |
|   network stack (TCP/UDP)  .  disk  .  filesystem        |
|   pipes  .  sockets                                      |
|                                                          |
|   hardware interrupts -> kernel wakes                    |
|   epoll / kqueue / io_uring                              |
+----------------------------------------------------------+

In relation to the Scenario 3, in my side using OSX, the syntax is Ok, but it doesn´t support high concurrency scenarios. Reviewing the difference between OSX, with Linux, I discovered kqueue from OSX and epoll & io_uring which Linux offer better performance.

Conclusion: In this round, I used better the objects but I discovered that OSX doesn´t support with my Laptop (M1 With 16GB) that it is not enough to handle 10k concurrent connection but in the pipeline using Linux, it is offer better performance.

---

BTW, I was able to solve the Scenario 3 in OSX, but using a non natural syntax using a Dynamic Headroom approach but I consider that the idea is to share natural syntax, not solution which solve a scenario for a particular OS.

[jabrena]

@jamesward Ready for the review

[jamesward]

Thanks!