use configured required update version

[suaviloquence]

• pass our deserialized overrides to the run_check_release function
• use the effective_required_update function in place of query.required_update whenever we previously accessed it to use the configured value
• add the beginnings of an integration test which tests precedence of workspace/package overrides (right now, it only tests required update, not lint level)

note: in lib.rs:460, when we don't have access to the current manifest, we can't read config at all, so we pass in an empty stack. If we were to read CLI config, we could store that in GlobalConfig and put that at the bottom of the stack for both situations we pass overrides

[obi1kenobi]

The implementation portion looks good. I have a couple of questions and concerns about some of the test setup. Nothing major, should be easy to sort out.

[obi1kenobi]

Might we want to add another layer of indirection here, like workspace.metadata.cargo-semver-checks.lints? With the current design, our entire metadata entry is reserved for lints and we can't add any other kind of config data at all.

[suaviloquence]

Sounds good. I can open a separate PR for this.

[obi1kenobi]

Could you either make sure to either make a new subdirectory for all test cases for package/workspace config testing, or follow the existing norms in the directory where you're adding the test crates?

Using baseline/current instead of old/new will probably break some of the tooling we use, such as this script for example:

cargo-semver-checks/scripts/regenerate_test_rustdocs.sh

Lines 46 to 48 in f8f89ec

	if [[ -f "$TOPLEVEL/test_crates/$crate_pair/new/Cargo.toml" ]]; then
	if [[ -f "$TOPLEVEL/test_crates/$crate_pair/old/Cargo.toml" ]]; then
	for crate_version in "new" "old"; do

[suaviloquence]

We can't use the regenerate_test_rustdocs.sh because we are passing the manifest path to cargo-semver-checks, so we don't want to generate rustdoc for these crates, which is why I didn't use new and old. It does make more sense to move them into a subdirectory, though.

[obi1kenobi]

Is this empty comment line intentional?

[suaviloquence]

Fixed, thanks!

[obi1kenobi]

This would be a great test case to add in a future PR!

[obi1kenobi]

I'm generally not a fan of commented-out code by itself, without any explanation or context.

Consider adding a brief doc comment explanation to the lib.rs in both current and baseline that describes the test case: what it tries to catch and how, and mention why this code is commented out here.

That will be super useful in the future, if this test case starts failing or needs to be modified by a future PR. We certainly won't remember why this code is commented out, and it's much easier to take 30s to write down that context now than to spend half an hour reconstructing it from scratch later.

[obi1kenobi]

If you could tweak the workspace_lint_config.rs check to be a bit more stringent, I feel good about the rest of this change and would be happy to merge it so we can move forward.

[obi1kenobi]

Possible other test: pass --manifest-path new/Cargo.toml -- the workspace manifest instead of the individual crate manifest -- and assert that the behavior is the same.

We want to make sure that crates are scanned with their crate's settings, even when the scan is triggered at workspace level.

This is fine to add in a subsequent PR if that's easier.