Changes

bts: set osmo-bts sched priority to 30

Change the scheduling priority from 10 to 30, as we are currently see
osmo-bts suffering from scheduling latency in jenkins even though we
don't run other jobs at that time:

  20250425034138405 DL1C ERROR PC clock skew: elapsed_us=387574, error_us=382959 (scheduler_trx.c:449)

This should fix that the kernel prioritizes other (userspace or kernel)
processes running on the same machine that have a higher priority. We
have seen such an improvement after increasing scheduler priority for
osmo-bts-sysmo too (see I2394e6bbc00a1d47987dbe7b70f4b5cbedf69b10).

Priority 30 is higher than 10. From sched(7):

> Processes scheduled under one of the real-time policies (SCHED_FIFO,
> SCHED_RR) have a sched_priority value in the range 1 (low) to 99 (high).

This testsuite currently gets executed through docker-playground and it
fetches this config from osmo-ttcn3-hacks (see
If15461240f3037c142c176fc7da745a1701ae3f8).

Related: osmo-ci I0162f7299c8e37f893ffa10ddc4c8edece29ed7f
Change-Id: I828422e2363a58ca8c19d0f1b8a1b7d4e4bc031e

tcpdump/dumpcap: move kill_rm_pidfile to inc file

Move kill_rm_pidfile out of the 4 ttcn3 tcpdump/dumpcap scripts into a
shared include file. Use the version of the function that only tries to
kill the command with sudo if it was started with sudo.

This fixes dumpcap not stopping if:

* it was started with ttcn3-tcpdump-start.sh (despite the name it will
  start dumpcap instead of tcpdump if dumpcap was found), where it gets
  started without sudo, and

* no rule is set in the user's sudoers file to run kill as root with
  NOPASSWD.

Change-Id: Ia63c37b54fb42a8c64a676334cef6f9df4152e18