Fix multiple cache loading message

[speeddragon]

We discovered an issue where the message was fetching data from cache 3 times during a call to a transaction ID.

Example: curl http://localhost:8734/ICC8rNh2ziKUDQHK7wnoaxtO0KNKYuW1dCwZc8B9e4g was accessed 2 more times than usual to the cache in hb_http:reply function because the message handed from dev_meta to hb_http:reply didn't contain the results fetched from cache.

Message was first loaded inside do_normalize_message call by dev_message:commit, which calls hb_message:convert and then hb_link:normalize, which loads the information in the cache.

In some cases, loading can be avoided by providing the header bundle: false, but this wasn't a solution here.

This is a list of the time spent in some function while processing the request.

sent, status: 200, duration: 23955, method: GET, path: /ICC8rNh2ziKUDQHK7wnoaxtO0KNKYuW1dCwZc8B9e4g, body_size: 570206867
-- store_read, path: ICC8r..B9e4g, duration: 595
-- store_read, path: ICC8r..B9e4g/data, duration: 6101
-- http_reply: duration: 15599
---- reply_handle_cookies: duration: 6710
------ store_read, path: ICC8r..B9e4g/data, duration: 6677
---- encode_reply: duration: 8883
------ store_read, path: ICC8r..B9e4g/data, duration: 5490

Improvement
http_reply: duration: 2703 (now) vs http_reply: duration: 15207 (previously).

[speeddragon]

By discarding this LoadedMsg, we discarded the loaded values from the cache. Msg value didn't contain the full values, and was used to attach merged commitments.

[speeddragon]

Changes under the verify made sense initially, but this breaks the dev_lua and dev_lua_test tests. The verify mode is called on dev_lua:decode and do_normalize_commitments fast mode.

[speeddragon]

I'm not sure of the use case for this test. Is there a behaviour where we expect a message that fetches data from cache always to return a linkify version, or should we always expect the values loaded from cache to be returned downwards, so we can avoid loading them again?

[speeddragon]

Initially, I was using LoadedMsg to return instead of Msg. This works for the use case of fetching an ID, but it breaks in the hb_cache match linked message test, because now the expected value is a linkify version, but the value itself isn't.

We can see the expected value as following:

#{<<"a">>=>#{<<"b">>=><<"c">>,<<"commitments">>=>#{<<"WnTWQDw6An5hmZioVWeN1C1xvYCxyrshVPBoBZvMCUU">>=>#{<<"commitment-device">>=><<"httpsig@1.0">>,<<"committed">>=>[<<"b">>,<<"d">>],<<"keyid">>=><<"constant:ao">>,<<"signature">>=><<"WnTWQDw6An5hmZioVWeN1C1xvYCxyrshVPBoBZvMCUU">>,<<"type">>=><<"hmac-sha256">>}},<<"d">>=><<"e">>}}

And the loaded value (the one returned) as:

#{<<"a+link">>=><<"WnTWQDw6An5hmZioVWeN1C1xvYCxyrshVPBoBZvMCUU">>}

I'm not sure if the test is wrong and we should always return the LoadedMsg, or we should check which one is the linkify version and return the other one.