Consider reserving new lint name at least one release before the implementation of the lint is released

Description

Assume clippy releases n, n + 1. If planning to implement a lint, called "new-lint" in clippy release n + 1, consider reserving the name, new-lint, in clippy release n. The idea is that the lint implementation should be a dummy that allows everything, for release n, and should switch to the actual implementation on release n + 1.

This would be nice to have, because some teams like to fix or allow n + 1 lints in version n and upgrade to version n + 1 only when all lints have been dealt with, i.e., the fixes or allows required by release n + 1 are added for code compiled with release n in CI or other infrastructure or team workflow. If the name were reserved in release n, then it could be allowed to avoid a lint in release n + 1.

The problem can be solved by individual users using the unknown-lint allow. But doing that spreads out the work among clippy users. The scheme I propose might reduce such busy-ness among users.

Version

rustc 1.80.0 (051478957 2024-07-21) (Fedora 1.80.0-1.fc40)
binary: rustc
commit-hash: 051478957371ee0084a7c0913941d2a8c4757bb9
commit-date: 2024-07-21
host: x86_64-unknown-linux-gnu
release: 1.80.0
LLVM version: 18.1.6

Additional Labels

No response

Start by reviewing how Clippy lints are introduced and how releases are planned; the issue does not name files or tests. Done means determining whether a lint name can be reserved with a harmless implementation one release before the actual lint, and documenting or implementing the agreed approach.