fix useless usage of dispatch() in the same cycle with aync IO

[Spycsh]

Hi! As discussed in previous undertow issue, Undertow does not let you both dispatch() and start async IO in the same dispatch cycle. Here dispatch() creates another redundant thread and may report some redundant errors in more complex cases.

One case I met is in my graph processing library based on Flink Statefun. I have two ingress stream, one edge stream for ingression of edges and another edge stream for query. Every vertex in a graph corresponds to a Function and each of them can pass messages to each other to do some computation (such as finding connected component). With the number of edges and vertexed increasing (in my case using the email_mini_edges_undirected which has 1000 edges), it will need more complex compuation and may be the reason to cause the following errors when dealing with query stream.

hesse_1                 | ERROR - UT005080: HttpServerExchange cannot have both async IO resumed and dispatch() called in the same cycle
hesse_1                 | ERROR - UT005071: Undertow request failed HttpServerExchange{ POST / request {accept=[application/octet-stream], connection=[k
eep-alive], accept-encoding=[gzip,deflate], content-type=[application/octet-stream], content-length=[30655], user-agent=[statefun], host=[hesse:1108]} r
esponse {Connection=[keep-alive], Content-Type=[application/octet-stream], Content-Length=[260436], Date=[Mon, 25 Apr 2022 08:42:30 GMT]}}
hesse_1                 | java.lang.IllegalStateException: UT000002: The response has already been started
hesse_1                 |       at io.undertow.server.HttpServerExchange.setStatusCode(HttpServerExchange.java:1388) ~[hesse.jar:?]
hesse_1                 |       at io.undertow.server.Connectors.executeRootHandler(Connectors.java:332) [hesse.jar:?]
hesse_1                 |       at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:254) [hesse.j
ar:?]
hesse_1                 |       at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136) [hesse.jar:?]
hesse_1                 |       at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59) [hesse.jar:?]
hesse_1                 |       at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [hesse.jar:?]
hesse_1                 |       at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [hesse.jar:?]
hesse_1                 |       at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88) [hesse.jar:?]
hesse_1                 |       at org.xnio.nio.WorkerThread.run(WorkerThread.java:561) [hesse.jar:?]

One interesting find is that these errors does not affect the correctness of final results of the query stream. They just bump out serveral times and seem to be in different redundant handling threads.

After deleting the exchange.dispatch(); statement in UndertowHttpHandler, these errors disappeared. Juding from the previous undertow issue I mentioned, I guess that would be a useless invoke of dispatch() here and can be safely removed.