Hash-based package routes

[nl0]

Description

Use top_hash in package routes, completely remove timestamps from the UI (timestamp revisions are still resolved, so it's backwards compatible).

TODO

• Changelog entry

[codecov-io]

Codecov Report

Merging #1938 (8d1a671) into master (4b5c6db) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1938   +/-   ##
=======================================
  Coverage   90.36%   90.36%           
=======================================
  Files          64       64           
  Lines        7764     7764           
=======================================
  Hits         7016     7016           
  Misses        748      748           

Flag	Coverage Δ
api-python	89.29% <ø> (ø)
lambda	92.40% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4b5c6db...8d1a671. Read the comment docs.

[fiskus]

I will do manual tests tomorrow

[fiskus]

Old URL works /b/fiskus-sandbox-dev/packages/fiskus/2011-11-16/tree/1605546363/
I don't know if this technically doable, we can make 301 redirect to new URL b/fiskus-sandbox-dev/packages/fiskus/2011-11-16/tree/67c766d5108b4dc2a7c3b74c8fd9287d880829158603de77bebf73288a7fdc81/

Also, I recall that we talked about short hashes (a la GitHub d5a76a3), but I don't remember what we decide

[nl0]

I don't know if this technically doable, we can make 301 redirect to new URL

not possible until we implement server-side rendering, tho we can redirect to the more "canonical" hash-based route on the front-end.

@akarve do we want to redirect to the new routes?

Also, I recall that we talked about short hashes (a la GitHub d5a76a3), but I don't remember what we decide

this will require backend support, so i think we should add this feature later (along with tags support)

[fiskus]

Didn't spot any bugs, except for inconsistency with old timestamps (not a bug, intentional)

[akarve]

Mostly works in testing. See a few notes in Slack.

[akarve]

This is reasonable behavior but I'm wondering if forwarding to a dedicated /h/ or whatever hash route is more correct in terms of traceability? Please make a note that /timestamp URLs are not forwarded in any way, but that the user remains at /timestamp.

[akarve]

To be clear I am totally cool with current behavior (honor both types of routes, no redirect). I am just asking if anything becomes cleaner or safer with two routes.

[akarve]

See potential bugs in Slack?