Use mutex to protect access to librpm

[fearful-symmetry]

Proposed commit message

More Librpm shenanigans. Turns out that it's possible for a user to run two instances of a metricset at once, which I didn't even know was possible or supported. However, librpm has some not-great threadsafety in it, and it's also possible for a shutdown operation to call dlclose while another thread is in the middle of accessing the SO. This adds a global mutex so we can't have multiple threads stepping on each other during RPM operations.

I tested this a bit, and I couldn't get it to crash while running multiple instances of the package metricset, but at this point librpm is so easy to break I would consider it more "best effort" than anything else.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

How to test this PR locally

You'll need to get auditbeat to run two instances of the metricset. Easiest way I've found to this is to create two separate system integration configs system-1.yml and system-2.yml with a basic config:

- module: system
  datasets:
    - host
    - package
  period: 10s
  state.period: 12h

Then set the file config in the main auditbeat config:

auditbeat.config.modules:
  path: ${path.config}/modules.d/*.yml
  reload.enabled: false

After you do that, just....repeatedly run auditbeat and send it random sigints.

[elasticmachine]

Pinging @elastic/sec-linux-platform (Team:Security-Linux Platform)

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @fearful-symmetry? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v8./d.0 is the label to automatically backport to the 8./d branch. /d is the digit

[nicholasberlin]

I see no other uses of openedLibrpm. LGTM

[andrewkroh]

@Mergifyio backport 8.15

[mergify]

backport 8.15

✅ Backports have been created

• #40592 Use mutex to protect access to librpm (backport #40525) has been created for branch 8.15 but encountered conflicts