Implemented the poll chain to await the download future that serialize polling

[polachandu]

Re-serialize by chaining each poll off the previous download's completion instead of a fixed timer — the same "single serial loop" guarantee that Go-OPA has. This makes bundle (and discovery) polling strictly serial, so overlapping polls can no longer run activateBundle() — and thus mutate the shared Store — concurrently.

Added a test confirming that downloads remain serialized even when activation exceeds the poll interval, so overlapping downloads cannot trigger concurrent activateBundle() calls.

Closes #113

[polachandu]

Hi @sspaink, please review this PR. Please post your comments/suggestions if any, happy to incorporate.

[sspaink]

The request has no .timeout(...) and the clients only set connectTimeout. Java's HttpClient has no default response timeout, so a server that accepts and never replies leaves sendAsync pending forever: whenComplete never fires, scheduleDownload is never called again, and polling stops permanently with nothing logged.

One line next to requestBuilder.build() fixes it:

requestBuilder.timeout(Duration.ofSeconds(/* e.g. the service's responseHeaderTimeoutSeconds */));

The timeout fails the future, handleHttpResponse logs it, and the chain keeps polling. (Prefer this over .orTimeout(...), which doesn't cancel the request — the stalled exchange could still land later and call activateBundle alongside a fresh poll.)