Implement Gecko-based DownloadManager

[pocmo]

We want:

• Use Gecko's networking stack for downloads (if we are using GeckoView)
• Avoid Android Download Manager issues like Investigate DownloadManager and cleartextTrafficPermitted issues #1801 and Bug 1280184

Soon we are going to have:

• A streaming download API in GeckoView: Bug 1522705.
• A concept-fetch implementation using Gecko(View): Create GeckoView implementation of concept-fetch #1328

Rough outline of work required:

• Exposing the stream in Download:

  • Extend Download to contain an optional concept-fetch Response object.
  • In the browser-engine-gecko-* component wrap the WebResponse in a concept-fetch Response (That's what Create GeckoView implementation of concept-fetch #1328 should get us) and pass that to Download

• Write a custom DownloadManager to be used by feature-downloads

  • On-going downloads need to be passed to a background service (with an on-going notification)
  • The download manager needs to retry downloads if they fail
  • We probably want to expose some controls in the notification (abort? pause?)
  • The download manager needs to have some kind of API that apps can use to get and list downloads and their state in the UI
  • Optionally pass off completed downloads to Androids Download Manager? Just so that they show up in the "Downloads" app?
  • Have a way to notify the app about completed downloads (Andorid's Download Manager sends a broadcast, I think)

┆Issue is synchronized with this Jira Task

[vesta0]

Now that we have the GV APIs, would be great to have an idea of the size of this work.

The goal is to oerform Downloads through GeckoView so we can get support for Cookies and allow for protected downloads (e.g. Bank statements).

[pocmo]

With our current sizing definitely an L.

This can vary in scope depending on how far we want to go on a "it works" to "deluxe solution" scale. For example:

• In this version, do we also want to store data about performed downloads so that Fenix can expose that in its library or do we just hand of completed downloads to Android's download manager to display it there?
• In this version, do we want to support retrying failed downloads?
• In this version, do we want to support pausing downloads?
  -> TL;DR: Do we just try to download once via Gecko(View) or do we need to store meta data about the download to support UI and actions like retry.

[NotWoods]

Currently this is blocked on a GV API: Bug 1530022

[pocmo]

@NotWoods This is the deluxe version where we take over a download from GeckoView. Right now we could still implement this by issuing a new request via concept-fetch. At the time of calling that delegate Gecko(view) has already cancelled the its own download progress.

[pocmo]

(The same we would need to do when re-trying)

[vesta0]

@pocmo

In this version, do we also want to store data about performed downloads so that Fenix can expose that in its library or do we just hand of completed downloads to Android's download manager to display it there?

• This is a post-mvp feature so ideally we want to go with the deluxe solution but considering other priorities maybe we can break it into steps? First step: just hand completed downloads to Anrdoid's download manager.

In this version, do we want to support retrying failed downloads?

-No but let's track it as a separate issue under the Download meta.

In this version, do we want to support pausing downloads?
-> TL;DR: Do we just try to download once via Gecko(View) or do we need to store meta data about the download to support UI and actions like retry.

-No but let's track it as a separate issue under the Download meta.

[cpeterso]

@NotWoods - Do you still need GV to pass the WebResponse to ContentDelegate.onExternalResponse? This is GV bug https://bugzilla.mozilla.org/show_bug.cgi?id=1530022.

[NotWoods]

As snorp said, it's good enough for now to make a second request to Gecko. Having access to the WebResponse lets us make a single request down the line.

[pocmo]

Let's file AC follow-ups though (if we haven't already?):

• Using WebResponse from ContentDelegate.onExternalResponse once available
• Save download jobs persistent so that they can be exposed in the browser UI, and retried etc.