Support multi-connection local BS repos

[mahaloz]

Problem

Sometimes, you want to have multiple decompilers connected to the same BinSync repo at the same time. You don't have a remote, so you want edits in all your decompilers to affect the local repo's version control. You can't depend on pulling from a remote.

In this case, BinSync completely blows up. Under the hood, we depend on Git, so you can't have two processes working independently to interact with the same local Git project. You need to synchronize actions, like commits and pulls.

Proposed Approach

To make this possible, the only real solution is to create a Git synchronization server in BinSync. This change is major if incorporated directly into the client of BinSync.
Since so much code will be duplicated if it is not, we should integrate this change directly into the Client.

I propose you do the following:

1. Create a new Python file and class called GitServer, this new class can operate in two modes:
   1. Object mode: does not spin up a real server at all and instead just does the operations in the same thread
   2. Server mode: spins up a server and takes requests over a PyRPC to do Git operations
2. Using the new GitServer object, update client.py to have a reference to it and use it for Git operations
3. Update use of any Client function that uses @atomic_git_action (and its subfunctions) to be in GitServer. As an example this func:

   binsync/binsync/core/client.py

   Line 277 in 70c0b9d

   def commit_state(self, state, msg="Generic Change", priority=None):

Steps for Completion

I think this should be completed in two parts:

1. Implement the GitServer, duplicating code from Client right now and keep both. We add a simple option to Client to use the server instead of using the local functions. Keep it experimental until the core team can do part 2:
2. Delete all the reused code in Client and make it use the GitServer object mode.

Limitations

• You will still need to be using 2 different users when connected on the same local repo, since we will not be trying to deal with conflicts in actions in the server. That would be out of scope :).
• In step 1 of the implementation, a single process using the server will be slower than its operating speed now. This can be bad when people use it for a fast CTF

Alternatives

• Instead of doing a full server, we can just have a shared file that we synchronize on. Hacky.
• Continue to not support multi-local connections, since it's already supported if you just copy the repo and have a remote repo

Additional context

This feature request was derived from discussion with Exiled on Discord: https://discord.com/channels/900841083532087347/930156084281356289/1189088322178531328.

[Exiled1]

Howdy! Super interested in helping out here! Incredibly detailed issue which helps me out a lot! :)