draft plan / implementation of peerdb api

[serprex]

needs unix socket to send comands to

needs resync command on the other end

we should support initial_snapshop_only (just like PITR or something)

builds on #65, meant for use validating that PR / this idea, but should be reevaluated after #65 merges

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ serprex
❌ harshil-goel
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[serprex]

this runs into cognitive dissonance: walshadow exists more precisely as a single mirror, so a true peerdb shim layer would need to maintain a metadata catalog & manage multiple walshadow instances. this shim layer exists as MVP without catalog

much of the graphs are synthesized (we don't have per-table granularity) & batching is rendered based on in-memory tracking. in the end this exists as a glorified pause/resume button & a create mirror endpoint for initial setup of one mirror. a specialized ui will be much simpler & avoid semantic gap