Strict checking of package installations.

[jedieaston]

Description of the new feature/enhancement

Add a --strict option to winget install which enforces certain additional checks to ensure applications installed correctly.

Proposed technical implementation details (optional)

Okay, before I start, this won't really make much sense until #1073 is implemented. Also, I know what I'm going to describe (if anyone even likes it besides me) will most likely need a spec, which I can draft.

#1073 is designed to allow package maintainers to enumerate every ARP entry a installer makes, so that winget has a better time matching. This should mean instead of the guesswork (which is pretty good, but not 100%) winget does now to try to match packages to the ARP table, it can know exactly what is supposed to be there.

I propose that a new option, --strict, be added so that if a package installs and the correct ARP entries are not made (so either less than enumerated in the manifest, or more, or just different/incorrect ones) that winget should say the install failed, perhaps print the differences (--verbose-logs?) and exit with a non-zero code.

This would help a ton with confidence in winget and allow it to start managing packages more than just lighting the firework and running away, which is the current functionality (well, it tells you if the installer said it failed, but the installers often lie). And of course, this functionality could be extended to do other checks based on assertions we can make by Installer Type. From a user perspective, I have more confidence, and from a package maintainer perspective this allows much better automation for package moderation (run the package with --strict. if the metadata didn't match, that's an error that's now super easy to push to a CI step instead of having to write code ourselves to read the ARP table. We shouldn't have to do that, winget already knows what it can and cannot match ;D)

There's a couple drawbacks to this, namely, that MSIX packages don't use the ARP table (but they have an equivalent), and portable applications don't either (but last I heard, the planned implementation of installing portable apps was to create an ARP entry for them. if that's still the case than it could work). It would of course be optional, as packages do all kinds of nasty things sometimes that we just have to go along with. (Chrome changes it's ARP entry on first run, for example. And if a user decides to use --custom, we can no longer guarantee what ARP entries will be made).

Please give me feedback and tell me if this sounds good/useful. I don't think it would be too bad to implement after #1073, but maybe there's some grossness I'm not aware of.

[jedieaston]

Also, there's not a lot of prior art for this. The only one I know of off the top of my head is SCCM's detection methods, but it doesn't rely on the ARP table for exe installers, instead opting to look for created files (which is more brittle, IMO).