Make reference counting more robust

[imp]

Summary

Currently, there's two races with the reference counting. One is a
race on the submission thread side. Prior to r333648 the refcount
protected against the completion from the xpt_action routine
triggering a wither and daclose before we could finish submitting and
reaquire the lock. This commit puts that back in place. However,
r333648 protects against another race that sometimes happens due to
bugs in GEOM where a request is submitted to the hardware and while
it's processing geom withers the device and calls daclose. There are
holes in GEOM's reference counting that allow this when I/O comes in
via geom_dev instead of geom_vfs (another commit will fix the known
hole where BIO_DELETEs are queued from ffs_blkfree via geom_dev
instead of geom_vfs which is how we saw this). While GEOM should be
perfect and not do this, at least one more hole still exists in
BIO_ZONE handling. To fail safe against this, and future GEOM bugs,
take out a second reference and release it in dadone like we did in
r333648.

Sponsored by: Netflix

Test Plan

similar changes would be needed in ada, nda and mda.

[mav]

It is OK to me. I still don't think protection against GEOM bugs belongs here, but so be it, since we any way have and acquire lock to protect that.

I would just not enumerate GEOM bugs in the commit message, if they are going to be fixed just by immediately following commits.

And may be reordered comments for refcount++ lines.

[imp]

OK. So it looked easy...

But if you look more closely, we're not really protecting things like we think and this is too racy. Opt for a different approach as done in D15517 where we keep outstanding counts reliably, but only detect issues in daclose rather than try to fix geom bugs. We'd have to do stupid locking to make second guessing GEOM's protection robust. mav was right about that all along.