Enable integration test workflow to more clearly communicate failure

[mfisher87]

Resolves #737

I don't have free time to debug the actual failures. Just getting the tests to fail loudly was a headache 😆 At a glance, I see a couple problems:

• We have some assertions at the module level that look like they should be set up in fixtures
• We're using unittest assert functions, so pytest is providing very poor error messages

[mfisher87]

Returned to draft; it was failing loudly in Act, but looks like still failing silently in GHA.

[betolink]

Thanks for noticing, I don't know when we started to exclude the integration tests!

[betolink]

Is there any reason not to merge? if the tests fail we should fix them. Maybe we need to visit the option to define a few popular datasets per DAAC instead of using random samples because some of them fail.

[mfisher87]

I think at minimum we need to update the fixture that allows 10% failure to communicate clearly that it was invoked before merging this one. Since it's a lot of work to rework the tests to remove that rule, this seems like a reasonable step. I'll try and take a look at that soon.

[mfisher87]

@betolink please take a look!

• I changed the hook so that instead of swallowing the failure, it uses a special error code 99. This enables us to tell the difference between a success, an acceptable failure, and an unacceptable failure.
• I changed the hook so that it only acts on error code 1; other error codes should not be modified because they indicate something other than "some tests failed". See comments for more!
• I changed the integration test script to do the "swallowing" and clearly communicate why. We can't use the pytest hook for this because then the print happens above the error summary and the user won't be able to find it among the logspew.

[mfisher87]

pre-commit.ci autofix