LWK cache removal: remove dependency on hash tag

[ok300]

This PR removes the dependency on the hardcoded hash tag

struct DirectoryIdTag = hash_str("LWK-FS-Directory-Id/1.0");

that is used to calculate the hash of the cache directory. Instead, empty_wallet_cache now clears all LWK caches.

The hash tag is pre-pended to a value X when X is hashed. This means the tag directly affects the resulting hash. In our case, X is the cache directory name.

There are two reasons for this PR:

• first, if this tag changes in a future LWK version, the previous empty_wallet_cache version would not be able to find and remove the existing cache. The tagged hash function of the same directory name will result in a different hash.
• second, we depend on the implementation of LWK calculates the cache directory hash. If that changes in a future LWK version, we would have to copy-paste the new implementation in our sha256t_hash_newtype!.

[dangeross]

I imagine changing the hash tag is in case that they want to invalidate the current cache, e.g. for a structure upgrade.

Is there a way to get the current hash tag used by LWK instead of hardcoding it?

I assume calling empty_wallet_cache clears all caches which then get rebuilt when used again. Any other consequences?

[ok300]

Is there a way to get the current hash tag used by LWK instead of hardcoding it?

I didn't find a way, although they could expose it. However, even if they expose it, we'd have to re-implement the hash mechanism (right now it's tagged hashes, but no guarantee it won't change). And even if they export the method by which they generate the hash, it would not be backward compatible for hashes generated with a previous tag.

This is especially tricky if this is used in mobile apps, where space is limited. If we risk ending up in a case where certain cache paths cannot be cleared, that's not good.

I think what this PR does, e.g. bypass the hash logic and clear all caches instead, is the most robust solution.

I assume calling empty_wallet_cache clears all caches which then get rebuilt when used again. Any other consequences?

No other consequences.

[dangeross]

LGTM

[hydra-yse]

LGTM