Disable --enable-asan and --enable-ubsan in CI

[behlendorf]

Motivation and Context

After this change the GitHub actions CI builders have detected
leaks in some of the ZTS support utilities and test cases. This results
in these CI builds always failing. Disable the use of these checks
for now to keep the CI happy.

https://github.com/openzfs/zfs/actions/runs/1794167045

@szubersk thanks for working on these changes, but it looks like
we're going to need to briefly disable them. I'm not sure how we
missed this in the original PR CI runs. Would you mind taking a
look in to this.

Description

For the moment disable the use of --enable-asan and --enable-ubsan
in the GitHub actions CI workflows. This functionality can be
re-enabled after the detected issues have been resolved.

How Has This Been Tested?

Pending verification from the CI that disabling these new checks
resolves the issue.

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.

[szubersk]

@behlendorf understood. It is absolutely weird that all of the sudden memory leak detection suppression stopped working. Did not happen once when I was working on that PR. I'm re-running the tests now to see what could go wrong (#13037).

[szubersk]

@behlendorf I'd not merge this PR yet. Looks like the run you mentioned was an outlier. Latest runs seem to be fine: https://github.com/openzfs/zfs/actions/runs/1799834360

[behlendorf]

@szubersk that's strange, thanks for checking. Yes, I'll hold off until it's clear where things really stand.

[szubersk]

So far we had 6 runs containing the asan/ubsan correction. None of them suffers from mysterious memory leak reporting.

• https://github.com/openzfs/zfs/actions/runs/1797129569 18 OK / 20 OK
• https://github.com/openzfs/zfs/actions/runs/1797376943 18 timeout / 20 import_rewind_config_changed FAIL
• https://github.com/openzfs/zfs/actions/runs/1799834360 18 OK / 20 OK
• https://github.com/openzfs/zfs/actions/runs/1800073353 18 OK / 20 zvol_misc_volmode FAIL
• https://github.com/openzfs/zfs/actions/runs/1800273393 18 OK / 20 zvol_misc_volmode FAIL
• https://github.com/openzfs/zfs/actions/runs/1800283451 18 OK / 20 OK

I can't really attribute the leaks to anything in the code base or tests. Explanation that something might corrupted RAM during e. g. runner hot-migration sounds naive.

Things unrelated to leaks that I see are:

• ZTS is able to time out once in a while. Is it worth to increase the timeout?
• It is not very well visible from this batch but import_rewind_config_changed and zvol_misc_volmode fail quite often, especially with asan/ubsan enabled. I'd consider marking those test cases as flaky.

[behlendorf]

Thanks for checking those test results. Then I'm going to go ahead and close this.

zvol_misc_volmode is already listed as a fauly test, so it appears to be failing multiple times in this case. I've gone ahead and opened a PR to increase some retries for this test case to see if that helps.