fix: auto-updater bug fixes

[dprats]

This PR refactors the self-updater functionality to be more reproducible and easier to test.

Here are the main changes:

1. The previous version of auto-updater would create a background thread that checked if there were any new updates
2. Then if it did, it would git pull the new code and then re-build from source

The problem with above:

1. There were issues with local vs production environments where pulling git pull may not work, sometimes it was as simply as the wrong directory.
2. Simply changing directories was one solution but others surfaced
3. rather than fight a potentially large batch of these small issues, I opted to refactor the code so teh auto-updater used a more standard approach: it uses the https://crates.io/crates/self_update crate that that replaces an existing executable with a new executable.
4. A benefit of the self_update crate is that it means i could delete lots of code i previously had since that crate handled

The main changes with this PR:

├── Cargo.toml  <--- Small changes.
├── README.md <--- Small changes. added commands for creating compiled binaries
├── src
│   ├── prover.rs.  <-- small changes in calling the updater crate
│   ├── updater.rs <--- removed lots of logic now that we use self_updater
│   └── utils
│       ├── mod.rs
│       └── updater.rs <--- refactor with self_updater. Most changes were here.
└── tests
    └── updater.sh <--- new bash script for testing. This replaces the old one.

1. changed the self-updating functionality to be one where the self_update crate was used to replace a running executable
2. Updated README so that there are commands for creating binaries by architecture
3. Implemented version tracking through a local version file
4. Created /tests/updater.sh test that builds the code and pulls the latest executable.

How I tested this PR

This PR was tested in the following way:

1. I would compile a executable and manually upload it to the 0.3.7 tag (see below)

2. In my local source code, I would make two small changes:

a. Change the cargo.toml version from 0.3.7 to 0.3.6

b. Comment out pub const UPDATER_COLOR: &str = BLUE; and un-comment pub const UPDATER_COLOR: &str = GREEN;

By doing the above the color of the [auto-updater] for 0.3.7 remained blue (like below)...

... while making the color of the [auto-updater] for 0.3.6 (in my local source code) became green...

This means that I would run code with green logging while the executable had blue logging. If the update properly worked, then it would switch colors on me while running. This means code can be deployed and the CLI self-updates

3. I would run the code locally and watch as my locally code "self-updated"

(see how the colors changed in the terminal after the executable self-updated)

Caveats

1. Github rate limiting - Github does throttle API requests (by IP) checking for latest versions of public repos like this one. I followed best practices (like setting user agents) so Github gives this wide berth. I believe this means we can get 50 pings from the same IP per hour. This should be enough for most people (but I did hit this limit many times while testing massive tests).

2. Other architectures - I have only uploaded the architecture for apple M1/M2 chip. The code should work with all the major ones (that is the intent of self_update) but this has only been tested with one architecture.

3. CI - This PR does not create CI integration for making compiled builds... right now its manual, Automation can be a different PR.

[github-actions]

Visit the preview URL for this PR (updated for commit 071cc87):

https://nexus-cli--pr75-dprats-binary-update-rye1pmyl.web.app

_{(expires Wed, 11 Dec 2024 22:08:56 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 815ec4c632754f56eccfacfc0919559f5a85a0f1}