Add timeouthandler

[andrewazores]

Wraps around Vert.x TimeoutHandler implementation to write a 500 response if a request is not completed by another handler within 15 seconds

Fixes #288

Easy ways to test: modify the 15_000 constant in the patch to a shorter period, like 500, and then do some operation like generating a report. Or, build a minimal image and try to request a web-client asset.

[vic-ma]

Some handlers, like the handlers to create a recording or view recordings present in a target, don't timeout even with a 1ms timeout. Is that okay/expected?

Also, needs a spotless format.

[andrewazores]

Some handlers, like the handlers to create a recording or view recordings present in a target, don't timeout even with a 1ms timeout. Is that okay/expected?

Hmm. I'm not sure why that would be - I've just wrapped around the Vertx standard timeout handler implementation and added it to the handler chain. Maybe whatever asynchronous monitor is watching for responses to be written to the context doesn't have the timing resolution to be so strict as to reject with timeouts as short as 1ms. Or perhaps we're blocking the event loop on those handlers and so the monitor doesn't actually get processed until after our handler executes - in which case, we need to change the isAsync return value on some handlers.

https://stackoverflow.com/questions/34483476/set-timeout-globally-for-all-operations-in-vert-x-router

The backing implementation is here but it doesn't provide much insight:

https://github.com/vert-x3/vertx-web/blob/master/vertx-web/src/main/java/io/vertx/ext/web/handler/impl/TimeoutHandlerImpl.java

Here's a piece of doc which references this setTimer:

https://vertx.io/docs/vertx-core/java/#_executing_periodic_and_delayed_actions

Anyway, the main use case here is to ensure that clients don't get left hanging if:

1. they try to load the web-client of a minimal build (I've done this to myself several times and it always takes me far too long to realize)
2. some wild exception occurs and a target connection or jfr-datasource/Grafana connection hangs/dies and we don't catch/handle the exception internally
3. we write some buggy handler or AuthManager or something that simply doesn't write a response in certain circumstances

All of these are cases where a long timeout of 5+ seconds should be easily caught by whatever async piece is monitoring us under Vertx's hood.