suspend_resume_single: clear pool errors on fail

[robn]

[Sponsors: Klara, Inc., Wasabi Technology, Inc.]

Motivation and Context

While working on something I kept hitting this test failing. And yes, I had bugs, but it sucked that rather than failing the test the entire kernel would just hang up.

The upshot is that if the timing is unfortunate, the pool can suspend just as we're failing because it didn't suspend. If we don't resume the pool, we hang trying to destroy it.

Description

Clear errors (resuming the pool) before trying to destroy the pool and clean up.

How Has This Been Tested?

Used to hit it fairly often in ZTS runs, now I don't (once attendant bugs were fixed).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[amotin]

I have no objections, but I wonder what cases it supposed to handle, especially if you won't recover the block device before it.