xen: fix blkback pushing responses before releasing internal resources

Fix a problem where the blockback driver could run out of requests,
despite the fact that we allocate enough request and reqlist
structures to satisfy the maximum possible number of requests.

The problem was that we were sending responses back to the other
end (blockfront) before freeing resources. The Citrix Windows
driver is pretty agressive about queueing, and would queue more I/O
to us immediately after we sent responses to it. We would run into
a resource shortage and stall out I/O until we freed resources.

It isn't clear whether the request shortage condition was an
indirect cause of the I/O hangs we've been seeing between Windows
with the Citrix PV drivers and FreeBSD's blockback, but the above
problem is certainly a bug.

Sponsored by: Spectra Logic
Submitted by: ken
Reviewed by: royger

dev/xen/blkback/blkback.c:
 - Break xbb_send_response() into two sub-functions,
   xbb_queue_response() and xbb_push_responses().
   Remove xbb_send_response(), because it is no longer
   used.

 - Adjust xbb_complete_reqlist() so that it calls the
   two new functions, and holds the mutex around both
   calls.  The mutex insures that another context
   can't come along and push responses before we've
   freed our resources.

 - Change xbb_release_reqlist() so that it requires
   the mutex to be held instead of acquiring the mutex
   itself.  Both callers could easily hold the mutex
   while calling it, and one really needs to hold the
   mutex during the call.

 - Add two new counters, accessible via sysctl
   variables.  The first one counts the number of
   I/Os that are queued and waiting to be pushed
   (reqs_queued_for_completion).  The second one
   (reqs_completed_with_error) counts the number of
   requests we've completed with an error status.


git-svn-id: svn+ssh://svn.freebsd.org/base/head@272321 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f