HTTP backlog wrong default value when using native epoll transport

When quarkus.http.accept-backlog is not configured and when epoll native transport (from Netty) is enabled, Quarkus won't be able to handle more than x requests concurrently, with x being the number of CPU core (in other words, it's pretty bad).

The workaround consists of configuring the quarkus.http.accept-backlog to -1.
This can be done from the application.properties or from the command line with:
java -Dquarkus.http.accept-backlog=-1 -jar ....

IMPORTANT: This issue does not affect native executables as the native epoll transport is not integrated in native executable.