jetcd use only one event-loop thread

**Versions**
- etcd: 3.4.10
- jetcd: 0.7.7
- java: 1.8

**Describe the bug**
There is only one event-loop thread, which may cause performance and other problems.

**To Reproduce**
Code:
```
public void test1() throws InterruptedException {
System.out.println("test start in thread: " + Thread.currentThread().getName());
for (int i = 0; i < 10; i++) {
getResponse("key" + i);
}
Thread.sleep(5000);
System.out.println("test end in thread: " + Thread.currentThread().getName());
}

private void getResponse(String key) {
client.getKVClient()
.get(ByteSequence.from(key, StandardCharsets.UTF_8))
.whenComplete((getResponse, throwable) -> System.out
.println("getResponse in thread: " + Thread.currentThread().getName()));
}
```

Result:
```
test start in thread: main
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
getResponse in thread: vert.x-eventloop-thread-0
test end in thread: main
```

[Similar problem here](https://github.com/etcd-io/jetcd/issues/1089#issuecomment-1275451145)

**Expected behavior**
The number of event-loop threads should be the number of CPU cores * 2.

**Additional context**

Start by reproducing the supplied Java example against jetcd 0.7.7 and inspect where the Vert.x event-loop is created or configured. Trace the client initialization and verify the resulting event-loop count; done means it no longer uses a single thread and matches the stated CPU-cores-times-two expectation.

Written by the indexing model from the issue text.