Revisit Clippy whitelisting

[bowenwang1996]

We should start enabling [clippy](https://github.com/rust-lang/rust-clippy) gradually. To do that, we should first figure out which rules trigger warnings and document them. The purpose of this issue is to get a list of clippy rules that we do not follow now so that we can fix them in the future.

[frol]

I assigned L1 implying that initial items should not be huge and Clippy + Rust compiler should guide us through, but if a bigger refactoring is necessary, we should decouple those into separate dedicated issues.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[bowenwang1996]

@matklad @nagisa curious what your thoughts are on this topic

[matklad]

While I am not a huge fan of clippy, for a big project with many developers, like nearcore, I think enabling clippy would be a net benefit, so we should do that.

Though, in terms of "keeping the code base sane", I don't think that's the most impactful thing. I'd say we should fix #4490 and improve compile times (by auditing our deps in Cargo.lock and cutting the cruft out) first.

[nagisa]

i definitely seen bugs being caught by clippy in CI, so I'm in favour of adding some of the clippy lints to at least CI.

[pmnoxx]

I'm a big favor of clippy. I detected many potential issues ahead of time. It also has many useful suggestions on how to write a cleaner, more readable code.I think we should enable it by default.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.