Automatically derive a cache descriminator from the wasmer version and selected functions

[aumetra]

Closes #2205

The hash is produced as follows:

BLAKE3(
  manual module version,
  wasmer version requirement,
  BLAKE3(function1),
  BLAKE3(function2),
  ...,
  BLAKE3(function_n)
)

And the hashes of the functions are lexicographically sorted since the inventory crate doesn't give us any guarantees about the order of hashes yielded.

[aumetra]

That is awkward.. for some reason the CI has a different discriminator value than I have on my local machine?

That's not right..

[chipshort]

Interesting, on my machine, the test also passes.

[kulikthebird]

I like that we have a mechanism that prevents errors during deserialization of modules in cache. I see some room for potential improvements/simplification of the current approach. If the comments I suggested are implemented, potentially we'll be able to move the only thing that is needed - hash_function - to cw-derive crate. Let's discuss that approach.

[chipshort]

Just changelog entry and the one open comment and then it's good to merge.

[aumetra]

Ugh, I forgot GitHub Actions always tests a fictional merge commit.. that behaviour throws me off so bad

[chipshort]

Yup, that also threw me off a few times before, but it's definitely the correct thing to do, since that's what you want to test.

[chipshort]

LGTM
I'm wondering if we also want to backport this?

[webmaster128]

This looks good at first glance. However, how does a node operator know which directories to delete and which ones to keep? Invalidated caches are not deleted automatically.

[aumetra]

The idea here was to have them look at the least-recently-used directory and delete the others.
Of course we could add something like a CLI flag to wasmd to output the current ID, something like wasmd --cache-version, which then outputs the hash of the cache version.

Depends on how much we want to proof this impl. But I feel like the LRU approach is fine, not perfect but fine.