fix: Multiple store read

[speeddragon]

This solves the issue where requesting http://localhost:8734/<ID> doesn't return the right content-type (and other fields).

The function hb_cache:store_read executes different actions (different hb_store calls) for each store. This will break the logic when calling type in one store and then list in another store, which always returns the ok tuple (hb_store_lmdb).

• We call list on the first store, which returns not_found, then call type on the second store, which returns composite.
• Then we call list on the first store, which always returns (even if empty), not accessing the value we want in the second store.

This PR changes this, so hb_cache:store_read processes the stores like hb_store, to run each logic separately for each store.

The change to lmdb file and the hb_cache:list function is optional, since I didn't detect an error with it, but this behaviour doesn't make sense because it is equal to the hb_cache:store_read.

resolve behaviour

We have two behaviours for resolve function:

• Return binary (resolved or unresolved path) or not_found atom in hb_store_fs.
• Return binary (resolved or unresolved path) in hb_store_lmdb
  • This is changed by this PR, to also return not_found.
• Return binary (resolved or unresolved path) or {error, any()} in hb_store_rocksdb. not_found is never returned.

The different behaviour between them is the reason to have different resolve handling in resolved_type and resolved_list. If we agree on modifying the return to always contain not_found (which may imply reading the object), this might not be needed.

resolved_read not implemented

hb_store_fs, hb_store_lmdb, and hb_store_lru already run resolve when read is called.

• hb_store_fs and hb_store_lru - read/2 resolves the key before trying to access it.
• hb_store_lmdb - tries to read first directly. If not successful, it will call resolve_path_links.

We can remove resolve call before each read, and trust the store to call it, or implement the resolved_read to make sure the resolve and read are always called for the same store.

Why not make type and list internally call resolve?

There are a few cases where type and list are used where resolved isn't needed or made in a different place of the function call.

Cases not changed from resolve and list to resolved_list

• hb_cache:read_all_commitments uses the CommitmentsPath inside its logic, not being able to collapse into resolved_list.

[speeddragon]

Tests pass with the same failures reported in #553

Failed: 4.  Skipped: 0.  Passed: 1373.

[speeddragon]

I didn't see a use case to return an empty array. The LMDB store didn't return not_found, but the hb_store_fs did, so swapping these two stores in the dev_query_test_vectors:simple_blocks_query_test will make the test fail (which shouldn't happen).

[speeddragon]

On edge, because LMDB store list was returning {ok, []} when it didn't find the information, the not_found case was never executed, making this request to not propagate to other stores.

This can impact performance, since now it will request to the configured stores. By limiting the scope to local we can mitigate this performance impact, but we need to be aware it will always be worse than just requesting to LMDB.

[speeddragon]

This test wasn't being used (maybe deleted by mistake?). Re-add it.

[speeddragon]

With read_all_commitments_by_store we make sure all actions only occour in one Store, and not retried in different stores if the item isn't found in the first one.

[speeddragon]

I'm not sure if this structure is possible in HB, but in this scenario, the old resolve followed by list would fail.