[Auditbeat] Cherry-pick #11628 to 6.7: Package: Nullify Librpm's rpmsqEnable

[cwurm]

Cherry-pick of PR #11628 to 6.7 branch. Original message:

We've had a number of problems with Librpm's use of signal traps (#10633). We've tried to fix it by using Librpm functions to disable them (#10694), but there is still the occasional test failure that seems related to it. I've also seen it happen at least once locally.

Now I've started testing the dataset on OpenSUSE and found our fix prevents it from working at all. The Python system test will reliably fail, with the Auditbeat test process shown as terminated by an uncaught SIGTERM. If I remove our disabling logic it works, but only on OpenSUSE, and again not on CentOS. I don't know exactly what in Librpm or our use of it is causing the behavior on OpenSUSE, my assumption is that something is going wrong with how we try to unset the signal traps, with the original ones not being restored.

So I'm proposing a more radical solution - overriding the rpmsqEnable function in Librpm that sets and unsets signal traps. This is possible since we dlopen/dlsym the library into the process, so any functions that are already defined will be used instead of what the library comes with. In a way, this is exactly what the rpmsqSetInterruptSafety function does in newer versions of Librpm (see rpm-software-management/rpm@56f49d7). It is also what gdb did with this patch following their bug report. I should have investigated their fix more closely the last time around.

Hopefully, this will eliminate the residual test failures.

I'll open another PR to enable the OS family suse for the package dataset that depends on this.

[elasticmachine]

Pinging @elastic/secops