Add password_hints_allowed config option

[jjlin]

Disabling password hints is mainly useful for admins who are concerned that their users might provide password hints that are too revealing.

[jjlin]

I added a commit to pin the Rust version to 1.61.0, since the newly-released 1.62.0 includes a version of Clippy that breaks the build (see rust-lang/rust-clippy#9014).

Given Clippy's tendency to occasionally break the build with new lints, I think it's better to pin a specific Rust version instead of using stable, and just update Rust along with the other project dependencies.

[BlackDex]

While we probably don't want the CI to break for testing, skipping a version because of a clippy lint issue is a bit to much i think. Especially if we are going to update it manually anyway as you recommend.

Also, those lint errors are fixed in the latest Diesel already, or at least ignored. Not that that will help with the current version though.

An other option would be to ignore that clippy warning during CI, instead of forcing something else then stable.
What do you think.

[jjlin]

1.61.0 is still a stable version. I don't see any particular reason to upgrade immediately to 1.62.0, and I'm not against waiting for 1.63.0 if that's when the Clippy fix will be released. But in general, I don't think that tracking a tag that can move out from under you (as stable did today) is good for build stability/reproducibility, hence why it's pretty standard nowadays to have lock files for project dependencies.

If you want to fix the build some other way though, that's fine with me.

[dani-garcia]

I think keeping a pinned version for the compiler makes sense, seeing as we already are doing exactly that for all other dependencies and docker images. It won't be a big step to update the rust-toolchain at the same time we do cargo update or modify the Dockerfiles.

This made me think that we should probably consider, now that we can compile in stable, if it's worth it to offer some minimum supported rust version guarantees, to help distro packagers and users who would rather use the official distro rust package instead of rustup. Debian bullseye is using 1.48 which is probably too old for us, so it's not a particularly pressing issue, but we could add a CI test for it anyway.

[BlackDex]

It's fine by me. But i think i need to take this into account with the MUSL base images, since i currently only build the latest stable when i update those images, and not the previous version.

So i either need to do that manually, or change the workflow to also build a specific version of Rust to match the one configured for Vaultwarden, so the C Libraries stay up-to-date for that version used.

[BlackDex]

Ok, updated my rust-musl project so that it will use the Vaultwarden version set in the rust-toolchain file. (Now i think of it, i probably need to do some extra checking there, but it's fine for now).

Also, that bug is fixed in the latest nightly it looks like, so that is nice.