fix(package): detect dirty workspace manifest

[weihanglo]

What does this PR try to resolve?

This addresses one of the corner cases of VCS dirtiness in #14967.

Workspace inheritance — like changing workspace.package.edition
to 2021 would actually make member Cargo.toml dirty,
but the current dirty status check doesn't capture that.

The solution here is

• Retrieve workspace manifest from Git index.
• Use the ws manifest from index to normalize package manifest.
• Compare the difference between normalized tomls from Git index and
  from Git working directory.

The implementation here is a bit ugly, as it exposes some internals
functions to pub(crate).

The current implementation also has performance issues. When the
workspace contains lots of members and has a dirty workspace manifest:

• It adds one extra manifest parsing and normalization for
  checking each member.
  • Parsing part can be cached for the entire workspace.
    However normalization cannot be skipped.
• It adds two TOML serializations for checking each member.
  • If we derive Eq for manifest types, we might be able to skip
    serializations and instead just compare them.

How should we test and review this PR?

Three tests are added to demonstrate that dirtiness check does not
work for Cargo.toml involved with workspace inheritance.

• One for basic check. If any change in workspace manifest could affect
  the inherited value, this should be caught as dirty.
• One for broken workspace manifest in Git index.
• The other is also for broken workspace manifest in Git index, but has
  no inherited field.

Additional information

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

The solution here is

• Retrieve workspace manifest from Git index.
• Use the ws manifest from index to normalize package manifest.
• Compare the difference between normalized tomls from Git index and
  from Git working directory.

This is a complex operation we are doing which I seriously question whether it is worth it vs something else like "its dirty if the workspace manifest is dirty" (without even bothering to check if the workspace manifest is different than the package manifest).

Similarly, we now include Cargo.lock and that could be dirty. Would we extend the same kind of "only if it affects this one package" style check for that case?

[weihanglo]

Good point. I do think this fix is a bit too convoluted to merge.

"its dirty if the workspace manifest is dirty"

This is actually a good compromise as users always have --allow-dirty to bypass it. Guess we could start an FCP or discussion during the meeting.

Similarly, we now include Cargo.lock and that could be dirty. Would we extend the same kind of "only if it affects this one package" style check for that case?

Ooops. I would rather not. Also we have --lockfile-path, which makes the entire story worse 😞.