Support hash-only build paths

[nkaretnikov]

Fixes #678.

Description

This pull request:

• adds hash-only build paths (v3)
• updates a test
• updates documentation.

Pull request checklist

• Did you test this change locally?
• Did you update the documentation (if required)?
• Did you add/update relevant tests for this change (if required)?

Additional information

How to test

Automated testing:

See tests changed in this PR.

Manual testing:

• with ~/.conda-store containing builds created on main, switch to this branch and create a new build: old and new builds should be accessible in the UI (lockfile, archive, and log links should work; marking one of the old builds as default should work)
• same, but also explicitly set build_key_version = 3 in the config
• same, but also explicitly set build_key_version = 2 in the config (make sure the previous default works with this PR)
• make sure two exact same specifications can be created in different namespaces and one of them is preserved when the other one is deleted.

[netlify]

✅ Deploy Preview for conda-store ready!

Name	Link
🔨 Latest commit	806da5f
🔍 Latest deploy log	https://app.netlify.com/sites/conda-store/deploys/66319c616dfacf0008a939a3
😎 Deploy Preview	https://deploy-preview-777--conda-store.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[nkaretnikov]

@jaimergp This is tested and ready for review, PTAL. Ignore the CI error, it's unrelated.

[jaimergp]

After the discussion in today's weekly:

Some background:

• I am concerned with adding more and more versions to the path settings. That's why I was pushing on "solving this once and for all". But that's just an opinion. If the team is ok with having several path versions, then my asks in items below are not so important.

My asks:

• Build IDs used to identify each attempt in the database shouldn't be so tied to the final path. Instead, we should resolve the lockfile first, and then compute the filesystem path from that output.
• Since that will involve more work, the current compromise of build-id + timestamp + username is ok. I do insist that this should just be an internal identifier in the database. The filesystem path could be computed later once input data is available.

As things stand, this is a fixed-length implementation of v2 right? We could try a hashed-lockfile in a future v4.

[jaimergp]

I talked with @trallard and we agree that we are good to merge, with the following reservations:

• Mark v3 as experimental (i.e. call it v3_experimental) with no guarantees of hash stability across conda-store versions (for now).
• Document that this is going to receive iterations where we experiment with different ingredients for the hash. In the future we might want to revisit the lockfile hashing until we arrive to a more robust solution.
• Add a little section to the https://conda.store/community/policies/backwards-compatibility docs.

How does that sound? Thanks!

[nkaretnikov]

@jaimergp PTAL. Will rebase after this is approved.