Fix FIPS builds not working with Ruby gpgme update

What does this MR do?

In the Ruby gpgme gem v2.0.22, https://github.com/ueno/ruby-gpgme/pull/166 modified the building of the C extension library to use pkg-config instead of gpgme-config since Debian has dropped the gpgme-config binary from its install.

However, this change quietly ignores failures when pkg-config does not include the gpgme.pc in its PKG_CONFIG_PATH (https://github.com/ueno/ruby-gpgme/issues/167). When this happens, the C extension library omits a dependency on the gpgme library and causes unresolved symbols to occur when the gpgme Ruby library is loaded.

This only happens in our FIPS builds because PKG_CONFIG_PATH is overridden with OpenSSLHelper.pkg_config_dirs, but /opt/gitlab/embedded/lib/pkgconfig needs to be included for other libraries that need pkg-config.

We can drop this workaround if Omnibus drops managing of the gpgme dependencies, since the gem will download and statically link the versions it needs automatically (#7344).

Related issues

• #7344
• #7345 (closed)
• Upstream fix: https://github.com/ueno/ruby-gpgme/pull/168

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion

Required

• Merge Request Title, and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com
• Pipeline is green on dev.gitlab.org if the change is touching anything besides documentation or internal cookbooks
• trigger-package has a green pipeline running against latest commit

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added
• Integration tests added to GitLab QA
• Equivalent MR/issue for the GitLab Chart opened