Serve more static files from nginx

[jtgeibel]

Serve more folders containing files with hashed filenames directly from
nginx with a max expiration date. Additionally, some unhashed static
files are allowed to be cached for up to 1 day.

These changes serve as a workaround for an authentication issue.
Currently conduit-cookie includes a Set-Cookie header in every
backend response. During the authentication steps, the popup window
requests static assets such as favicon.ico and cargo-{hash}.png.
If these assets are served by the backend, they will echo whatever
cookie was sent in the request. Therefore, there is a race between the
request to /api/private/session/authorize?... and requests for these
static assets. If a request for one of these assets is sent before
authorization is complete and the response arrives after successful
authorization, then the stale cookie will be stored again by the
browser, overwriting the contents.

I've opened conduit-rust/conduit-cookie#12 to track the progress of the
proposed long-term solution. This commit should be sufficient to fix
the behavior for now and should reduce the number of requests for these
static assets (due to improved caching).

Closes #2252
r? @carols10cents

[Turbo87]

wow... how on earth did you figure that one out?! 😱

[jtgeibel]

Yeah, this took a lot of time to track down! Every time I thought I had reproduction steps or saw a pattern, everything would start working again. I tried all sorts of things like: reloading the page at different points, deleting the cookie as if it had expired, adding extra cookies, and even manually setting isLoggedIn to 1 in local storage. I couldn't reproduce it locally at all (maybe the timing over loopback is too consistent), but had probably a 15% failure rate in staging. Eventually I determined that the trigger was probably random, or at least independent of any of my steps, but there were oh many false leads.

I couldn't find a way to use the developer tools within the short-lived popup window, so I eventually took a closer look at the staging logs. The extra requests to favicon.ico stood out just enough to draw my interest. To confirm my suspicious I used the recently added logging metadata (needing to open #2383 along the way) to log the session data before and after the handler, and deployed that to staging. After several retries I hit the failure again and was able to observe the cookie values sent and confirm they were different from the successful sequences.

[carols10cents]

Whew! lgtm! Great work tracking this down! ❤️

@bors r+

[bors]

📌 Commit 45c7511 has been approved by carols10cents

[bors]

⌛ Testing commit 45c7511 with merge 9be7706...

[bors]

☀️ Test successful - checks-travis
Approved by: carols10cents
Pushing 9be7706 to master...