Changes

client: use pcap_dispatch to avoid extra pkt buffer copy

pcap_next() allows use of returned buffer until next time the same API
is called. In order to do so, it internally calls pcap_dispatch() with
an internal handler (in the case of linux pcapint_oneshot_linux()).
That handler basically memcpy()s the pkt buffer obtained in the
pcap_dispatch callback into a temporary static buffer which is then
returned.
We don't need any of that here, and by using pcap_dispatch() directly
(as recommended in pcapint_oneshot_linux() function documentation) we
can skip an extra memcpy() of each packet buffer captured.

Furthermore, it will allow us processing multiple packets from the
captured queue (RA_SOCKET+mmap implementation in linux) in one poll
iteration if several packets have been captured. This will be done in a
follow-up patch.

pcap handle is marked non-blocking to allow polling from it without
ending up blocked. Applying filter is moved beforehand, as seen in
libpcap capturetest example.

Related: SYS#7290
Change-Id: I055efb66fac5e04c541d75ec2c0f654cdfb17838

client: Process up to 10 recorded pkts per poll iteration

This should decrease CPU use of lipcap capturing under high capturing
load, which is welcome now that we support osmo_io with io-uring backend
on the Tx side towards osmo-pcap-server.

The processing number is kept low in order to avoid starving the event
loop, as well as avoid filling up the msgb queue of the Tx side towards
osmo-pcap-server.

Related: SYS#7290
Change-Id: I569fc8489bae2b829ef4040d3c5111a61129de68