Let the application supply the auto-merge policy; add Repo::merge_heads

[somasekimoto]

Why

Auto-merge resolves concurrent heads with the policy named in the genesis metadata, and the only one is last-writer-wins over the whole payload. That is right when the payload is one value. It is wrong when it is several with different convergence rules — Monas's payload is a content body next to an access policy. A head that only advanced the policy still carries the body it inherited; a concurrent head that only changed the body still carries the policy it inherited. Whichever is newer wins both fields, and the other head's change is lost although nothing competed with it. In Monas this is a revoke being erased by a concurrent write (Monas-project/monas, docs/revoke-write-bypass-investigation.md on feat/policy-aware-merge).

The library cannot merge such a payload field by field — it does not know the fields — so it now lets the application say how.

What

• Repo::with_merge_policy(Box<dyn MergePolicy<P>>): installs a policy used for every auto-merge in place of the genesis-named one. Nothing changes for callers that do not install one.
• ResolveInput::parent_payloads: the head's parents' payloads, so a field-aware policy can tell what a head changed. LwwMergePolicy ignores it; a parent missing from storage is skipped.
• Repo::merge_heads(genesis): run the auto-merge now and return the single head. The lazy merge inside the next commit is too late for a caller that wants to read the converged state first — latest() alone picks one concurrent head by timestamp. Repo::heads(genesis) exposes the current head set.

The policy is process-local and never travels with the data; every replica must install the same one (documented on the method).

Tests

• installed policy is used over the genesis's "lww" and sees each head's parents
• resolver attaches parent payloads
• named policy still applies when nothing is installed
• merge_heads converges two heads, is idempotent, returns None for unknown content

110 tests pass, clippy clean.

[Yu-da-1]

元々がそうなっていたってのがあるけど、現状はnodeを作成するタイミングにマージポリシーを適用させる状態になっていると思うのですが、こちらについてどう思いますか？
今回修正してもらって気づいたんですが、そうなるとマージポリシーは途中から変わりうる = 「過去と現在で形が変わる可能性がある」ってことだと思っていて、それって自分たちが保証したいこととはずれそうだなとは思っています。一方でそれはライブラリを使う方側が考えれば良いとも思い、どっちに責務を置くべきなのかが気になりました。

[somasekimoto]

指摘のとおり、今回の実装では注入したpolicyがgenesisのpolicy_typeを無視するため、同じ履歴に別の規則を黙って適用できる状態になっていました。

ノード作成時にマージ結果を保存すること自体よりも、「その履歴で使うと記録された規則」と「実際に使う実装」が結び付いていない点が問題だと考え、2528d75で修正しました。

責務は次のように分けています。

• ライブラリ：genesisのpolicy_typeに対応する実装を選び、対応実装がなければエラーにする。
• アプリケーション：独自policyのマージ処理を実装し、各state nodeへ互換性のある実装を配布する。

新規作成時には選択したpolicyをgenesisへ記録し、以後のマージはその指定に従います。既存LWW履歴は、独自policyを注入してもLWWのまま扱います。また、同期先でも同じmetadata・CIDを復元できるよう、operationにその情報を保持させました。

ただし、ライブラリが検証するのは規則の名前と実装の対応であり、同じ名前で提供される実装の中身まで同一かは検証しません。そのため、挙動を変える場合は別のpolicy名にするなど、実装の互換性はアプリ側で管理する、という分担です。