Fix panic when resizing zvol

[smh]

Summary

Fix zvol resize panic due to recursion on dp_config_rwlock

This change elimiates additional differences from upstream including changes missed during the merge of upstream

The upstream change "3464 zfs synctask code needs restructuring" restructured zvol_set_volsize to avoid the recursion on dp_config_rwlock, but this was missed when originally merged in by r248571.

These changes also relied on bring in changes from upstream:
3557 dumpvp_size is not updated correctly when a dump zvol's size is changed
which where also not present.

Additionally performed a direct comparision and diff minimisation from current upstream version (b515258), including using a #define to map zfsdev_state_lock to spa_namespace_lock.

Finally this reverts the change to the uio_loffset validation checks in zvol_read and zvol_write as the processing loops would never process uio_loffset = volsize made by r264145.

[smh]

@mav is it right to revert the change to the validation of uio_loffset?

[xmj]

I can confirm that this patch fixes the issue I saw with FreeBSD 11.0-CURRENT builds with the GENERIC and debug stuff (WITNESS, INVARIANTS):

Before, I saw the following assert error and kernel panic when doing 'zfs set volsize=2*(current volsize) zpool/path/to/zvol':

solaris assert: !rrw_held(&dp->dp_config_rwlock, RW_READER), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_po ..

Now, it works fantastically. :-)

[smh]

For reference on the uio_offset change I've found the following which indicates this was fixed upstream, so it could be a miss-merge on our part:
https://github.com/illumos/illumos-gate/commit/73ec3d9c430feaac0947f81e1a6e8f3df2a13894
6596419 zvol character (raw) devices allow read/write past the end of the device

[smh]

Looking to get this committed early next week, if anyone needs more time to look though this please lmk, otherwise based on xmj's positive feedback I'll get this into the tree.

[smh]

Previous fix to uio_loffset by r264145 was correct, it fixes broken EOF detection in upstream.

[smh]

This is closed by:

• r276069
• r276066
• r276063