Wrapper login listener not unblocked in some cases

[DasBabyPixel]

Stacktrace

from debugger:

park:-1, Unsafe (jdk.internal.misc)
parkNanos:410, LockSupport (java.util.concurrent.locks)
connectToNode:146, Wrapper (eu.cloudnetservice.wrapper.impl)
invokeSpecial:-1, LambdaForm$DMH/0x00007fcb1f19a000 (java.lang.invoke)
invoke:-1, LambdaForm$MH/0x00007fcb1f19c800 (java.lang.invoke)
invoke_MT:-1, Invokers$Holder (java.lang.invoke)
invokeMethod:71, MethodHandleUtil (dev.derklaro.aerogel.internal.util)
invoke:584, DefaultMemberInjector$InjectableMethod (dev.derklaro.aerogel.internal.member)
injectMethod:371, DefaultMemberInjector (dev.derklaro.aerogel.internal.member)
injectInstanceMethods:330, DefaultMemberInjector (dev.derklaro.aerogel.internal.member)
inject:166, DefaultMemberInjector (dev.derklaro.aerogel.internal.member)
executeMemberInjection:73, MemberInjectionRequest (dev.derklaro.aerogel.internal.context)
finishConstruction:527, DefaultInjectionContext (dev.derklaro.aerogel.internal.context)
resolveInstanceAndRemoveContext:100, ContextInstanceResolveHelper (dev.derklaro.aerogel.internal.context.util)
resolveInstance:79, ContextInstanceResolveHelper (dev.derklaro.aerogel.internal.context.util)
resolveInstance:63, ContextInstanceResolveHelper (dev.derklaro.aerogel.internal.context.util)
instance:139, DefaultInjector (dev.derklaro.aerogel.internal)
instance:121, DefaultInjector (dev.derklaro.aerogel.internal)
instance:60, DefaultInjectionLayer (eu.cloudnetservice.driver.inject)
instance:60, UncloseableInjectionLayer (eu.cloudnetservice.driver.inject)
main:77, Main (eu.cloudnetservice.wrapper.impl)

Actions to reproduce

It happens really rarely, and is not an error per se, but rather a bothersome inconvenience.
In the last year this has been happening every now and then, and it is always confusing, because the server doesn't start (30s delay).

The call to LockSupport.parkNanos(TimeUnit.SECONDS.toNanos(30)); will wait the entire 30 seconds, because the
AuthorizationPacketListener does not unblock (probably already unblocked).
I assume somewhere there is another hidden LockSupport#park... call (in CompletableFuture#join() or when sending a packet, idk exactly where)
This will "consume" the LockSupport#unpark(Thread) from the AuthorizationPacketListener, and the server will wait 30 seconds before proceeding to start.
The login ends up being successful, so the response packet does indeed arrive.

A simple solution to this could be using a CountDownLatch

Screenshot of debugger:

CloudNet version

[04.03 18:07:18.466] INFO :
[04.03 18:07:18.466] INFO : CloudNet Blizzard 4.0.0-RC12-SNAPSHOT 649acb52
[04.03 18:07:18.466] INFO : Discord: <https://discord.cloudnetservice.eu/>
[04.03 18:07:18.466] INFO :
[04.03 18:07:18.466] INFO : ClusterId: ae0bbf39-****-431d-****-857e2580ae82
[04.03 18:07:18.466] INFO : NodeId: Node-1
[04.03 18:07:18.466] INFO : Head-NodeId: Node-1
[04.03 18:07:18.466] INFO : CPU usage: (P/S) .24/3.54/100%
[04.03 18:07:18.466] INFO : Node services memory allocation (U/R/M): 4808/4808/16384 MB
[04.03 18:07:18.466] INFO : Threads: 46
[04.03 18:07:18.466] INFO : Heap usage: 89/256MB
[04.03 18:07:18.466] INFO : JVM: Eclipse Adoptium 23 (OpenJDK 64-Bit Server VM 23.0.1+11)
[04.03 18:07:18.466] INFO : Update Repo: CloudNetService/launchermeta, Update Branch: beta (development mode)
[04.03 18:07:18.466] INFO :

(running custom build based on 8bfd442)

Other

No response

Issue uniqueness

• Yes, this issue is unique. There are no similar issues.