lock-file should expose md5 and sha256 hashes

[asford]

@jvansanten This is probably closest to a feature request for your work. I'm happy to implement if the project is +1.

References:
mamba-org/mamba#1209
#131

The not-yet-released conda-lock file format should support specification of package hashes in multiple hash formats,
encompassing (at least) the md5 and sha256 has formats potentially available in upstream package metadata.

This will be extremely useful to allow forward-compatibility in the lock format as conda/mamba evolve, and allow additional tools to interpret the generated locks.

As a motivating example, mentioned in #131, having both the sha256 and md5 has available allows tools to fetch and cache packages by the "more common" sha256 while allowing explicit lock spec generation using the md5 hash.

As a specific motivating example, our company maintains an internal tool very similar to conda-lock that maps conda environments to bazel build targets. As we're using bazel to fetch the locked packages, we must specify them as http_file targets with sha256.

As a strawman, I would propose changing the hash field from a string:

hash: md5:deadbeef

to an explicit mapping of hash algorithms to hashes:

hash:
    md5: deadbeef
    sha256: c0wafaba

These values would be populated from the upstream package metadata, which must provide md5 and may provide sha256.

In cases where an upstream sha256 is not available it would not be included in the mapping, or could be backfilled by conda-lock by inspection of the package post-lock.

Ie:

hash:
    md5: deadbeef

is valid output.

[jvansanten]

I think this is a good idea. You're not the first to request multiple hashes, but the specific motivating example here trumps my rationale for storing only a single hash (laziness, specifically not wanting to think about logic for choosing which hash to use at render time).

So, 👍🏻 from me and looking forward to a PR.

[mariusvniekerk]

Thanks for taking this one @jvansanten !

I think once this gets in we can should do a release of the version with the new lockfile format.

This delay would prevent the situation where there are two new combined lockfile format essentially at launch.

[mariusvniekerk]

Started on this in #146