cuprated: killswitch and version module

[hinto-janai]

What

• Adds a killswitch mechanism for releases before v1
• Changes --version to output more information in JSON

Why

Tue, Jan 14, 2025, 18:28:22 - hinto: I've also considered not releasing binaries in case `cuprated` exposes major network problems, no binaries would a hacky but real limiter to that problem
Tue, Jan 14, 2025, 18:29:02 - hinto: or if `cuprated` itself is the issue
Tue, Jan 14, 2025, 18:30:04 - SyntheticBird: The `what is important / what should be focused on in Cuprate` is going to be interesting discuss (to re discuss in an extent).
Tue, Jan 14, 2025, 18:30:16 - boog900: yeah we will need to stress that alpha means don't trust with anything critical
Tue, Jan 14, 2025, 18:31:05 - Rucknium: Zcash has a different release philosophy. At least with the old C++ zcashd, old releases had an intentional killswitch after their "expiration date" ev
en without a hard fork. Just to put it in context.
Tue, Jan 14, 2025, 18:32:02 - boog900: Oh yeah that was another idea, we could put a killswitch in the alpha binary to force people to update.

Thu, Jan 16, 2025, 21:28:13 - hinto: After reading https://github.com/monero-project/monero/pull/9668#issuecomment-2594104964 I think it may be a good idea to open up the security discussion
and gather wider consensus before releasing a v1 `cuprated` binary. If the security scope is being set at a malicious upstream or miscompilation then I think `cuprated` could represent a much
 more real and practical tool to be used by a malicious actor if something like a chain split bug were to be found.\

For reference, there were audits for `reth` and `zebrad` before v1 release:
- https://github.com/paradigmxyz/reth/blob/main/audit/sigma_prime_audit_v2.pdf
- https://www.nccgroup.com/media/bw3nq0vm/_ncc_group_zcashfoundation_e005955_report_2023-06-27_v10.pdf

For the alpha build, releasing build instructions / documentation should be okay without further review...? An argument could be made that it's not difficult to use an alpha `cuprated` for th
e same attacks but then again there's probably cheaper and more profitable ways to attack the network?
Thu, Jan 16, 2025, 21:30:21 - Mαlοri: I agree with the comment
Thu, Jan 16, 2025, 21:30:54 - hinto: Regardless I think the killswitch is a good idea, perhaps just a thread that slowly loops on `assert!(current_timestamp() < some_timestamp)` sounds ok?
Thu, Jan 16, 2025, 21:31:51 - SyntheticBird: fwiw I would like to avoid the killswitch to kill the node at runtime but rather block at next start
Thu, Jan 16, 2025, 21:32:12 - boog900:  no it should kill at runtime IMO

[SyntheticBird45]

Let a comment regarding 3/6.