feat: verify libpathrs version at both compile time and runtime

[lifubang]

We currently lack a clear error message when the libpathrs version is insufficient.
To address this, we should check the libpathrs version at both compile time and runtime.

[cyphar]

Do we have something like this for libseccomp?

libpathrs v0.2.5 did have breaking C ABI changes (which I did to "get it out of the way" before a proper release), but that is not something I plan to repeat.

Also we currently use the pathrs_version symbol which was only defined for v0.2.5 and thus you should not be able to compile nor run runc with a pre-v0.2.5 version already. Did you manage to run into this situation in practice, or is this meant as a preventative measure?

[lifubang]

Hi @cyphar, Thanks for the quick review!You're right -- we don't have an equivalent runtime/build version check for libseccomp (we mostly rely on pkg-config + linker errors). libseccomp updates are relatively infrequent (the 2.5.x series lasted almost two years, with 2.6.0 released earlier this year), so the current approach has worked fine.For libpathrs the situation feels a bit different because the library is still relatively young. We are particularly concerned about cases where a patch release (e.g. 0.2.6 fixing a bug or security issue in 0.2.5) becomes available, but users or distro packagers stick with 0.2.5 since there is no clear enforcement or error message. The pathrs_version symbol already protects us from anything older than 0.2.5, but doesn't help with newer patch versions.This PR was mostly preventative + UX-focused: give users and packagers a clear, actionable error ("version X is too old, please upgrade to >= Y") instead of obscure link/runtime failures. Given that you don't plan further breaking ABI changes after 0.2.5, would you prefer we:

1. Keep only the build-time pkg-config check (and drop the runtime one), or
2. Simplify the implementation further, or
3. Drop the whole thing if you feel the existing symbol + documentation is sufficient?

Happy to adjust based on your recommendation -- you're the expert on libpathrs stability.

[rata]

My guess is that new features will be conditional to what is found at runtime and we won't require them. But I'd like to know what @cyphar thinks about this.

[kolyshkin]

@cyphar @lifubang speaking of libseccomp, I've implemented some measures in seccomp/libseccomp-golang#129. Alas it's a lot of changes, but what can we do?

[kolyshkin]

this path is exercised by every runc command, and twice by runc create/run/exec. Seems a tad wasteful to me.