File downloads should not use createObjectURL

[andrewazores]

Requires backend support:

#319 (comment)
#319 (comment)

Currently, when downloading template XMLs, report HTMLs, or recording JFRs, the application handles firing the HTTP request with the appropriate Authorization header. The remote asset is then downloaded into memory as a blob, assigned an object data URL, and then that URL passed to the browser's native file save dialog to "download" - despite the fact that we have already downloaded the file from the server and are holding it entirely in-memory, without any progress bar or ability to cancel the download on the user's side.

This download flow should be replaced by a normal download flow handled by the browser, where the application simply points the browser at a URL to download from the server, and the browser continues to display a dialog to the user confirming the choice, showing progress in its Downloads indicator, and handling the actual data transfer and memory/disk management.

To do so will require some backend changes so that Authorization headers do not need to be passed with the GET request to download the assets. A Cryostat user session cookie could be used for this purpose, to authenticate a logged-in Cryostat user for the duration of their login session (ex. generate a token and send it back with Set-Cookie on POST /api/v2/auth?), or as in the blog posts linked in the above comments, there could be a very short-lived token generated for each specific asset download request, which the client must include as a query parameter to download the actual asset file on a subsequent request.

We can probably use JWTs for either user login tokens or for per-request download tokens - need to do more research here. https://github.com/auth0/java-jwt
https://vertx.io/docs/vertx-auth-jwt/java/