Remove download manager wish list

The website currently has a page of "requirements" for Newport, the
download manager. This page lists a number of recommendations for
requirements were drawn up after the initial implementation and review of
Newport. Looking at the commit history for Newport, it seems that these
requirements have never been implemented. Newport is not widely used and
is part of the legacy application framework and thus isn't receiving any
development effort.

As this page doesn't reflect the reality of what's available or likely to be
available in Apertis, delete it.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>

content/download_manager.md

-+++
-date = "2015-09-21"
-weight = 100
-
-title = "Download manager"
-
-aliases = [
-    "/old-wiki/Download_manager"
-]
-+++
-
-Newport is a download manager capable of downloading files from the
-internet for local storage.
-
-Currently the download manager does not specify the type of files that
-could be downloaded for the automotive system. The files could be audio,
-video, applications, map data, system images, *etc*. It uses sqlite db
-to store and retrieve the download links.
-
-The source code can be found at
-https://gitlab.apertis.org/pkg/target/newport
-
-## Requirements for Newport (download manager)
-
-State: **Draft**. These should not be implemented until discussed and
-finalised. Open questions are inline in italics.
-
-### Requirements
-
-1.  Provide support for multiple downloads with continuous progress
-    updates.
-2.  Provide persistence of all downloads which would be stored
-    periodically so that pending downloads start automatically on next
-    startup. Apps might not be able to access the content of a download
-    before it is complete.
-3.  Provide support for pausing, resuming and canceling a download. The
-    D-Bus object representing an ongoing download should persist until
-    it is explicitly closed by the app.
-4.  Maximum number of active parallel downloads must be a per-user
-    preference. Changing this is a privileged operation, only available
-    in a settings UI.
-5.  Provide an application with a list of its pending per-(app, user)
-    downloads when queried. This is intended for restoring state after
-    restarting an app.
-6.  Provide list of downloaded URIs per user. This is intended for a
-    per-user privileged downloads UI.
-7.  Provide mechanisms to clear history of downloaded URIs per
-    app/session/all. each app may clear its own per-(app, user) download
-    history; only the privileged downloads UI may clear the per-user
-    history.
-8.  Apps must be able to access D-Bus APIs for only the downloads
-    started by them. Similarly, they must only be able to receive
-    signals about those downloads.
-9.  Download manager should run as a per-user daemon.
-10. Continuously supervised by the bandwidth management
-11. Download manager is *not* in charge of deleting downloaded files
-    (potentially unless the download fails). If disk space needs to be
-    reclaimed, this should be done by the resource manager.
-12. Download manager must signal success, failure and progress updates
-    to the clients, including estimated remaining time.
-13. The local destination filename for requested downloads should be
-    validated as being strictly beneath either `~/Downloads` or
-    `/Applications/$app_id/Downloads/$username`. If it already exists,
-    it will be overwritten, without following symlinks (to avoid symlink
-    attacks).
-      - *Exactly which paths should be used? The current paths
-        demonstrate the different use cases to be supported, but might
-        need rewording.*
-14. The download manager may download directly to the destination file,
-    or to a temporary file which is then atomically renamed to the
-    destination.
-15. Check the available/allocated disk space before starting a download.
-    If there is not enough space, enqueue the download as paused.
-16. App access to download APIs must be explicitly requested in the app
-    manifest.
-17. Downloads must be paused if the user is on (or moves to) a network
-    connection which is not set in the user’s (per-app, per-user)
-    preferences as to be used for downloads.
-18. Downloads must be paused if the user is on (or moves to) a metered
-    connection (where the user is charged per unit of traffic
-    transmitted).
-19. Downloads must be paused if the user is on (or moves to) a
-    connection which is slow (for some definition of ‘slow’ — for
-    example, a 2G connection).
-20. Downloads may be resumed if the user moves to a network where
-    neither of the above three points apply.
-21. Each network connection may have a traffic cap imposed by the OS —
-    the total amount downloaded over some time period (for example, a
-    month, for a monthly internet contract) must not exceed this cap.
-    Downloads must be paused to respect this.
-      - *Further clarification is needed as to whether the traffic cap
-        only applies to "downloads" via this framework, or whether it also
-        covers applications' other traffic, for example browsing photos on
-        Facebook. This interacts with the resource management service.*
-
-### Security policy
-
-Based on the above requirements, this is a suggested security policy:
-
-  - Newport can write to its own private temporary directory, accessible
-    to no other applications.
-  - Newport can read from and write to files strictly beneath
-    `~/Downloads` iff requested to by an app which wants to download a
-    file to there. This includes overwriting existing files, being
-    careful to avoid symlink attacks. It also includes creating new
-    subdirectories if necessary.
-  - Newport can read from and write to files strictly beneath
-    `/Applications/$app_id/Downloads/$username` iff requested to by
-    `$app_id` (suggested implementation: validated using
-    `GetConnectionCredentials`) which wants to download a file to there.
-    This includes overwriting existing files, being careful to avoid
-    symlink attacks. It also includes creating new subdirectories if
-    necessary.
-  - Newport D-Bus APIs are callable by any app which requests download
-    support in its manifest.
-  - Newport D-Bus APIs on a specific download are callable only by the
-    app which initiated that download (suggested implementation:
-    validated using `GetConnectionCredentials`).

content/release/15.09/releasenotes.md

@@ -160,7 +160,7 @@ of a setuid executable, reducing the risk of security vulnerabilities.
 ## Newport (download manager) design review
 
 There has been an extended period of API and security review on the
-design of the [Newport download manager]( {{< ref "/download_manager.md" >}} ),
+design of the [Newport download manager](),
 including a series of patches which rearchitect its D-Bus API.
 
 Discussion about the Newport API and security review can be found on