CA-146664: xen-netback: fix guest Rx internal queue races

There are two race conditions in the guest Rx internal queue.

a) Because the length is increased after enqueuing the skb, the
   atomic_add() may race with the guest Rx thread dequeuing the skb
   and freeing it.  The atomic_add(skb->len,...) will thus add a bad
   length.

b) Stopping the queue races with the guest Rx thread draining the
   queue.  Thus the queue may be stopped when it is empty and it will
   never be woken/started again.

Fix these races by holding the queue lock while adjusting the length
or stopping/waking the queue.

Also, it is not straight-forward to reason about the queue flow
control when the guest Rx thread may requeue an skb back onto the
internal queue.  We can avoid this by only dequeuing an skb iff there
are enough ring slots free for the largest possible skb.

This could potentially affect poorly implemented guests that do not
keep at least 18 Rx slots filled. Such guests are a) not expected to
exist (Windows PV drivers have always kept the Rx ring full, and Linux
guest have kept at least 32 slots filled); and b) would not work the
large GSO packets anyway.

This should not affect throughput since large GSO packets would have
required 18 slots anyway.
CA-146727: xen-netback: reduce max guest Rx internal queue length

This reverts a9276a513143cc9ff00630c5425da81fe67ea7c7 (CA-145482:
xen-netback: increase maximum length of internal guest Rx queue).

Whilst increasing the maximum internal queue length to 1 MiB,
increased aggregate performance by ~5% (fixing a regression the limit
introduced), it reduced single stream performance by ~30%.

Change the maximum back to 512 KiB (i.e., half a ring of pages).
CA-144273: xen-netback: wake queue when guest Rx is ready

netif_carrier_on() was incorrectly assumed to start all the queues.
This meant that if it took 10 s (the drain timeout) for a VIF to go
from CONNECTED to up in the guest, then it was possible for the queue
to be stopped (if > 512 KiB was queued in this time) and the Rx stall
detection to trigger.  When guest Rx became ready, the queue was not
restarted and guest Rx would not work.

Whilst investigating this two more bugs were identified:

- Unsafe use of the unlocked skb_peek(&vif->rx_queue) because skbs
  could be removed concurrently (in the xenwatch thread on
  disconnect). Now only the guest Rx thread removed skbs from the
  internal Rx queue.  This allows the thread to safely use skb_peek()
  without locks.

- The guest Rx wait timeout was not being recalculated when an skb was
  queued to an empty queue.  Now a hand-rolled wait_event_timeout()
  variant is used which recalculates the timeout each iteration.

The queue drain and Rx stall detection is also refactored to to make
the two behaviours independent.

- Queue drain: Only skb's older that the drain timeout are dropped.
  This sets a clear upper bound on the length of time an skb can be
  queued for.  For a guest being destroyed the maximum time needed to
  wait for all the packets it sent to be dropped is still the drain
  timeout (10 s) since it will not be sending new packets.

- Rx stall detection: An Rx stall is detected if there are not enough
  Rx slots and an Rx packet hasn't been queued for a while.  The stall
  timeout defaults to 60 s.  Rx stall/ready only affects the carrier;
  it does not drain, stop or start any queues.
CP-9681: export some event channel functions as non-GPL

This allows third-party backend drivers that are not properly tagged
as GPL compatible to use event channels.

The changed symbols are:

   - bind_interdomain_evtchn_to_irqhandler
   - notify_remote_via_irq
   - unbind_from_irqhandler
CA-138936: extract ABI file even if the old one is missing

When going from +0 to +1 we don't have an old ABI file but we want to
extract the new one so it can be easily added to the abi-version
patch.
CP-9807: backport Xen EFI support