Add rust-version to Cargo configuration

[mina86]

Add package.rust-version to all Cargo.toml files so that users don’t
get mysterious compiler failures when trying to build the project with
unsupported compilers.

Issue: #5452

[matklad]

Example error

λ make release
cargo build -p neard --release
error: package `near-chunks-primitives v0.0.0 (/home/matklad/projects/nearcore/chain/chunks-primitives)` cannot be built because it requires rustc 1.59.0 or newer, while the currently active rustc version is 1.56.0
make: *** [Makefile:22: release] Error 101

Not a huge fan of "remember to upgrade this config in ten different places" workflows, as most likely we won't be able to keep this consistent. But it's worth a try!

[matklad]

(one alternative is to pin this only for, eg nearcore/Cargo.toml, which should make, eg make release behave)

[nagisa]

I'm of a similar opinion as @matklad. Having rust-version specified for each crate would make most sense if we maintained and tested each crate separately. Since this is a monorepo-ish setup, specifying rust-version for just the most commonly depended on crate within the workspace is going to be easier to work with.

[miraclx]

Of the most commonly depended on, I think the best candidate would be near-primitives

[matklad]

To clarify, given that we do publish things to crates IO (without much semver guarantees), I thing there might be some merit in just specifying this for everything.

[mina86]

Looks like opinions are split regarding whether this should be just in near-primitives or everywhere. I’m gonna mark it automerge in the current form (with rust-version added to all Cargo.toml). If anyone has strong opinions remove the label and discuss it.

[pmnoxx]

As with every decision, there are benefits and drawbacks:

Benefits:

• external developers who use our packages, will know what we require new version, making it less confusing
• next time we upgrade Rust version, every code owner will get informed, we will be able to check what new features the next version offers, and decide whenever we should use any of them
• we already put version inside each crate, whenever we bump up version everyone already gets notified. So, as long as we do the version update, at the same time, as rust_version update, we will not be adding any more extra work, than we already are doing.

Drawback:

• Every code owners needs to accept the change. However, we already do that with every version bump. So, we are not really making the situation worse than it already is.
  It's a good idea, to always bump the version when rust_version changes.

I think we should do it.