Apply the egress sequence offset in userspace passthrough

[nickakt]

The kernel module adds the egress sequence offset to every packet it forwards;
userspace passthrough did not, unless a fixed egress SSRC was set. Decoding for
an injection mix lowers the offset by one per packet. After inject stop the
first packets left userspace with their original numbers and the kernel then
applied the offset, so the receiver saw the sequence jump forward and back.
SRTP derives the packet index from the sequence number, and a receiver discards
packets behind its replay window: a WebRTC client, whose window is 1024 packets,
went silent for 20 seconds after a 40-second injection.

Userspace passthrough now applies the offset, on a copy of the whole packet
since other sinks share it, for handlers the kernel may forward. A stream
forwarded under the sender's own SRTP key and SSRC keeps the sender's numbering
instead, whether or not it is re-encrypted on the way: a renumbered packet would
repeat an index the sender has used, so the offset is dropped for that stream,
in userspace and in the kernel alike, and the receiver sees a gap. A fixed
egress SSRC, echo, transcoding and DTMF injection number the stream themselves
and keep the offset.

Verification:

• t/auto-daemon-tests-inject.pl gains nine sequence scenarios (RTP, SRTP, the
  sender's key with and without recrypt, a 65535 crossing, repeated
  injections, a fixed egress SSRC across a source change); the first eight fail
  on master and pass with the change.
• make check with RTPENGINE_EXTENDED_TESTS=1: the same results as master.
• Through the kernel module (6.8): fixed egress SSRC with a source change, and
  DTMF injection, under SDES keys shared end to end, three runs each against
  master and this change: the sequence stays continuous and the kernel keeps
  forwarding while the daemon is stopped with SIGSTOP.

[nickakt]

Kernel-path check of this revision, with the module built from this tree on kernel 6.8, SDES keys shared end to end, three runs per build and scenario (all three identical). For 25 packets of the observed phase the daemon is stopped with SIGSTOP; 25/25 arriving means the kernel forwarded them. Re-kernelization after the event is in the daemon log, no No support for kernel packet forwarding lines, no SRTP authentication failures.

build	fixed egress SSRC + recrypt, source changes SSRC	DTMF injection (telephone-event)
master d590a62	10009 → 10010 → 10011 … contiguous	contiguous
89c3677 (previous revision)	10010 from userspace, then 501 from the kernel: 149 packets behind a 1024-packet replay window	one backward step 10017 → 10016, 2 repeated indexes
3c7a736 (this revision)	contiguous, as master	contiguous, as master

Userspace: the nine inject-suite scenarios pass (0 authentication failures of 812), three more times under AddressSanitizer without a report; make check with RTPENGINE_EXTENDED_TESTS=1 matches master.

3c7a736 differs from 0538522 in the ninth test only: the fixed egress scenario changes the source without an injection. With an injection, the first packet of the player and the last passed-through packet can leave with the same sequence number; master does the same (2 of 3 runs under AddressSanitizer), so that is not this change.

[nickakt]

Upstream: sipwise#2209