pre_hash should recursively rely on pre_hash

[Ngoguey42]

Follow up on https://gitlab.com/tezos/tezos/-/merge_requests/2543.

pre_hash is Unboxed.encode_bin unless when the user provides a custom one through the v, like and map contructors.

The problem is that when computing the pre_hash of a container type (e.g. list), the custom pre_hash of the substructures contained in that container are simply ignored.

I guess a solution would be to add a is_pre_hash : bool parameter to all the function in Encode that traverse the runtime types so that the | Custom and | Map cases of Encode.unboxed and Encode.t select the right function given that boolean.

[craigfe]

This issue seems to have resulted in #60 having introduced an incompatibility with Irmin master. The following diff seems to fix it, but it's a hack:

diff --git a/src/repr/type.ml b/src/repr/type.ml
index 3b89218..965e45e 100644
--- a/src/repr/type.ml
+++ b/src/repr/type.ml
@@ -21,6 +21,7 @@ open Utils
 
 let pre_hash t =
   let rec aux : type a. a t -> a encode_bin = function
+    | Attributes { attr_type; _ } -> aux attr_type
     | Self s -> aux s.self_fix
     | Map m ->
         let dst = unstage (aux m.x) in

We should fix this, as it's a very subtle behaviour that Repr's test suite does not cover.