Reproducible builds
## What
This is a request for comment on reproducible builds for Cuprate.

Similar to https://github.com/monero-project/gitian.sigs, this would allow anyone to deterministically build Cuprate binaries.

This process would also be used for the public release binaries (as Monero does).

Assuming this should be focused on, it still may be very far out - this work would be done around the time Cuprate is ready for a stable public release.

## How
An incomplete list of some steps that could be involved.

---

### `cargo vendor`
The source code for the entire `cargo` dependency tree be fetched and stored locally with:
```
cargo vendor
```
which stores all dependencies within `vendor/`.

After editing the projects `.cargo/config.toml` to:
```toml
[source.crates-io]
replace-with = "vendored-sources"

[source.vendored-sources]
directory = "vendor"
```
`cargo build` would build using the local files.

This may not be needed, depending on the below.

---

### Semantic Version
Source versions could be controlled.

In all of Cuprate's `Cargo.toml` files, we must use one of:
- A fully specified version `v1.0.0`, not `v1`
- Specific commits to dependencies

This applies to all crates within Cuprate and external submodules, not just the root workspace `Cargo.toml`.

Committing the `Cargo.lock` with these specific versions would guarantee people are building the exact same dependencies (with the caveat being yanked crates).

---

### Build System
Any data used in the build process outside of the Cuprate tree and/or dependent on the build system must be accounted for.

Notably:
- System libraries
- `cfg!(target_os = "windows/macos/linux/etc")`
- Input/output of system-specific `build.rs` scripts

The same [gitian process](https://github.com/monero-project/monero/blob/master/contrib/gitian/README.md) Monero uses could be used for this.