erofs: Validate directory '.'/'..' entries and nlink counts

[cgwalters]

When going over dumpfile canonicalization related to hardlinks, it made me think about the potential for skew between EROFS nlink on inode vs what's actually present.

This then led to: our reader should be enforcing this matches. And while there, my agent also pointed out we could be checking ./.. among other things.

The previously unused InvalidSelfReference and InvalidParentReference error variants are now wired up.

Assisted-by: OpenCode (Claude Opus 4)

[cgwalters]

Man, the flakes on c9s are annoying. That's tracked by bootc-dev/bcvk#153 ...will investigate

[jeckersb]

Hm I consistently get these two failures when running the unit tests locally:

---- erofs::reader::tests::test_rejects_corrupted_directory_nlink stdout ----

thread 'erofs::reader::tests::test_rejects_corrupted_directory_nlink' (222124) panicked at crates/composefs/src/erofs/reader.rs:2439:13:
fsck.erofs should also reject corrupted directory nlink
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- erofs::reader::tests::test_rejects_corrupted_nlink stdout ----

thread 'erofs::reader::tests::test_rejects_corrupted_nlink' (222126) panicked at crates/composefs/src/erofs/reader.rs:2387:13:
fsck.erofs should also reject corrupted nlink


failures:
    erofs::reader::tests::test_rejects_corrupted_directory_nlink
    erofs::reader::tests::test_rejects_corrupted_nlink

test result: FAILED. 120 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.46s

Haven't looked further to see what that's about.

[giuseppe]

LGTM

[giuseppe]

I've removed the PR from the merge queue because of #272 (comment)

[giuseppe]

@cgwalters if you think it is fine to merge, I am fine with it

[cgwalters]

Hm I consistently get these two failures when running the unit tests locally:

Thank you for looking at this! Indeed the devcontainer doesn't have erofs-utils installed and neither does the CI env...and my bad for not noticing this drift!

And now that I do...it turns out that while fsck.erofs does catch missing ./.. it doesn't catch incorrect nlink, which seems like a pretty basic thing for a fsck implementation to miss. But OTOH it matters a lot less for a readonly filesystem...