Coverity model should know that KM_NOSLEEP means no sleeping

[ryao]

Motivation and Context

This fixes an old oversight. I doubt it affected the accuracy of coverity very much, but it is an improvement that I caught while discussing the latest coverity results with Rob N.

Description

The model is updated to only consider sleeping when KM_NOSLEEP is not used. Previously, it always assumed sleeping was possible. Coverity has some checks that can detect issues when sleeping is done, although it is very rare, so it is unlikely this affected us.

How Has This Been Tested?

The new model file will be uploaded to coverity shortly. We will know if it causes anything to go haywire soon afterward, but that is highly unlikely.

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.

[robn]

I think the same change needs to be made to the vmem variants.

[ryao]

I think the same change needs to be made to the vmem variants.

Done.

[ryao]

I am withdrawing this, as while it is technically correct, a regression in Coverity causes the models being touched by this to be broken both with and without this, so there is no point in doing things the correct way. I might include this as part of a different PR including the fix for the major issue in Coverity, but it would be purely a documentation matter in that case.