Hardcoded auth parameters in DesiredLRPs

[onsi]

The droplet download URLs hardcode the basicauth username and password.

This is bad. It is a two-fold concern: security (one user/pass to rule them all) and, more importantly it's a disaster in hiding:

A deploy that modifies these credentials will fail catastrophically - the CC will roll and the subsequent Cell deployment will fail (new containers won't be able to download their droplets).

An Idea

1. We teach the DownloadStep about HTTP headers.
2. The CC creates a random token when the droplet is uploaded and associates this token with the app.
3. We add an internal unprotected endpoint that one can use to download droplets. You must provide the correct random token as a header to fetch the droplet.

Pros:

• token per app: there's no centralized username/password combo that gives you the keys to the entire kingdom
• clear policy to revoke the token: create a new droplet (i.e. cf push).
• naturally complements the Diego lifecycle: if you change the token (i.e. by pushing) you necessarily change the process guid which means you have to create a new DesiredLRP. tl;dr we don't ever try to update the token for an existing DesiredLRP.

Cons:

• still passing tokens down to Diego. (No way around that?)
• ??

[onsi]

@sykesm makes the excellent point that this is basically just a non-expiring signed URL. Will add a story to that effect.

[onsi]

Added https://www.pivotaltracker.com/story/show/93733722