Remove db_state DB_NOFILL checks from syncing context

[amotin]

Syncing context should not depend on current state of dbuf, which could already change several times in later transaction groups, but rely solely on dirty record for the transaction group being synced. Some of the checks seem already impossible, while instead of others I think we should better check for absence of data in the specific dirty record rather than DB_NOFILL.

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.

[rrevans]

+1 to the design rule that db_state is for open context only, and it might be worth stating that in a comment somewhere since it's not immediately obvious that state transitions are only protected by range locks.

(Also there's some subtlety here that range locks for cloning must be aligned to whole block boundaries to protect against different open context calls trying to change the state of the block in conflicting ways, and that should probably be documented in brt.c if it's not already.)

This looks good, though maybe consider adding assertions for the invariants in the sync code and/or open context?

• db->db_state == DB_NOFILL implies head dirty record dr_data == NULL
• db->db_state == DB_NOFILL implies db->db_level == 0

These assertions would maybe fit into dbuf_write which is the only place in sync code that inspects the open context state for evictions or other complications.