Sync and Link Shulker Boxes across Multiple Machines

[OpenBagTwo]

Blocked by #26, #27

GIVEN Alex has EnderChest set up on multiple machines, which are aliased as follows:

• alex-battlestation
• alex-couch-pc
• alex-steam-deck

AND in the EnderChest folder of Alex's couch PC she has four ShulkerBoxes, each with the following shulker.cfg file:

• 01 Global

   ; 01 Global/shulker.cfg
   [minecraft]
   *
   
   [hosts]
   *
   
   ...

• 02 Controller Configs

   ; 02 Controller Configs/shulker.cfg
   [minecraft]
   *
   
   [hosts]
   alexs-steam-deck
   alexs-couch-pc
   
   ...

• 03 April Fools 2023

   ; 03 April Fools 2023/shulker.cfg
   [minecraft]
   23w13a_or_b
   
   [hosts]
   alexs-couch-pc
   
   ...

• 20 Steam Deck Optimizations

   ; 04 Steam Deck Optimizations/shulker.cfg
   [minecraft]
   1.19.4
   
   [hosts]
    alexs-steam-deck
   
   ...

WHEN she opens the command-line on her Steam Deck and runs the following command from her root minecraft folder:

enderchest open && enderchest place

THEN all shulker boxes will be synchronized from her couch PC, including the ones that aren't needed by the Steam Deck, and including changes to the Steam Deck only Shulker that were made on the Couch PC
BUT only shulker boxes with a "hosts" configuration matching the Steam Deck (explicitly listing alex-steam-deck or using the wildcard) are synced to the individual instances
AND ONLY AFTER the command line has printed a summary of the changes (see notes) and has had at least five seconds to interrupt the sync

SO that:

• files and configurations in the first two boxes are synchronized across all relevant instances across both machines
• the contents of "irrelevant" shulker boxes are backed up across all machines
• Alex can make changes (such as updating a mod) to machine-specific instances rather than make all local changes locally

Notes

• this is an explicit change from how the "local" folders are managed today, in that under the current system, local changes are pushed (backed up) but never pulled
• each host must be named (no "local"), and that name will need to be managed centrally (probably in enderchest.cfg)
• the "pull" strategy currently is "grab from the first available," as opposed to "grab from any and all available" which I think is still right, as:
• enderchest close, which isn't mentioned in the Gherkin, but is in scope of this work should push local changes everywhere with the same summarize-and-wait-before proceeding behavior
• the low-effort implementation of the change-summary would be to print the raw output of rsync --dry-run, but it would be really neat if we could get a higher-level summary that said explicitly called out the boxes that were receiving updates
• in the future it would be great to set an option for handling the summarize-then-sync behavior, allowing the user to choose between (1) just sync immediately; (2) confirm always; (3) confirm when overwriting or deleting local files
• as an implementation idea--might it make sense to use git instead of rsync? Not only is git better supported on Windows (I think), but git can easily flag "merge conflicts" and even suggest auto-merges. 🤔

[OpenBagTwo]

While there's plenty I still like about the idea of git support (#30), it's worth noting that it doesn't really solve the Windows problem as the user would still have to run a git daemon.

I think if easy windows support is the priority, the route to go down is samba.

As it stands, my thinking is that this issue will only cover syncing behavior for one protocol`? and then have spin-off stories (which can be priority-ranked) for the other implementations.

And to that end, the implementations I'm considering would be:

• file (would it be cheating to start with this one?)
• rsync (which has a URI syntax! yay!)
• sftp (which has a native-python implementation in the form of paramiko)
• smb
• git