Improve serving of prehashed assets

[theodorton]

See rails/jsbundling-rails#21 and rails/jsbundling-rails#15 for motivation. Also builds on the work in #714.

Given an already digested asset chunk-9ad2e0aa4f0e481dfc8eaa4dc850eab8.js, we want to make sure that Sprockets can serve this file.

There are currently two problems that needs to be resolved:

1. Sprockets::Server will currently try to lookup chunk.js when accessing chunk-9ad2e0aa4f0e481dfc8eaa4dc850eab8.js
2. Sprockets::Server expects ETags of assets and digests to be the same, but that cannot be predicted as the hashing algorithm and version configured in the Rails application will not match whatever configuration the upstream build process used to digest the file.

• Sprockets::Server is now changed so that if it fails to find chunk.js, it will instead try and load chunk-9ad2e0aa4f0e481dfc8eaa4dc850eab8.js.
• When this code path is triggered, the fingerprint will be hijacked and replaced by Asset#etag so the ETag header behavior is consistent with other assets served by sprockets.

[brenogazzola]

Yeah. Adding a fallback behavior does look much better than trying to stop sprockets from removing the fingerprint and should work for solving ou development problem. Does this work too with the assets precompiled?

[theodorton]

Does this work too with the assets precompiled?

Yes, it should work for both the development and production scenario.