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.)

[polachandu]

Looking into it.

[sspaink]

Ah, my bad — requestBuilder.timeout() covers the whole exchange, not just headers, so wiring it to a 10s value would've killed any download slower than that. Real problem, and my suggestion walked you into it.

I'd rather not add download_timeout_seconds though. OPA doesn't have a bundle download deadline at all, and response_header_timeout_seconds is headers-only — "does not include the time to read the response body." The catch is the buffering body handler, not the timeout: switch to BodyHandlers.ofInputStream() and the future completes as soon as headers land, so the deadline only covers headers and a slow body just keeps streaming. No 300s default needed. Bonus, cancel the original future on timeout and my orTimeout gripe goes away too.