If the active request were to panic, we need to ensure all the waiting
goroutines get woken up.

Avoid locking around db requests by only locking around active requests
and always creating an active request if there is none. A nice side
effect of this is that if many parallel requests for remote media come
in (a common case) then only one database query is made for the duration
of the query.

mediaapi/writers/download: Add local download support

So that they apply to all log messages thereafter

/upload handler and storage database

* Add API for querying the state after a list of events

* Implement state after events API

* Actually implement the API

* Reorder .travis.yml

* Comments

* Use common.MakeAPI

Content-Disposition is only used for communicating the filename. It does
not need to be stored in the database as we have upload_name anyway. It
does not need to be in types.MediaMetadata and does not need to be
logged.

Reorder functions to have public API functions in alphabetical order at
the top, internal package functions at the bottom in call order.

Use RawURLEncoding to avoid padding the hash with '='.

Use stronger types for paths in public API.

Simplify comments.

Skeleton for the Media API

Content-Disposition is not a valid request header and so it must be
evaluated from the upload request's filename query parameter.