Update libbpf to 1.8.0

[d-e-s-o]

Update the libbpf submodule to version 1.8.0 to get the latest and greatest.

[d-e-s-o]

This doesn't really seem backwards compatible given the rename of bpf_link_info__bindgen_ty_1__bindgen_ty_11__bindgen_ty_1. At the same time, I don't see how we can prevent/fix that.

[d-e-s-o]

I think we probably just have to bite the bullet and accept certain risks here: a strict backwards compat story for a bindgened library is simply not feasible with such a moving target of the underlying C header. If new types are added in the middle numbers embedded in types will shift. Similarly, some bitfield replacements may cause constructors to be removed etc.

[alexforster]

We had to freeze at a certain bindgen version too recently, right? Maybe we make the contract explicit: the version number of this crate corresponds to the version of libbpf it wraps. It is not a semver version.

[d-e-s-o]

Yeah. It's still a bit unfortunately for something like libbpf-rs, which re-exports libbpf-sys. Basically, we'd strictly speaking follow this convention then. That, and it's simply not how Cargo treats the versions we use. It will always see 1.7 and 1.8 as compatible (it's just the baked in semantics, I'd think).

[alexforster]

An alternative would be to only ever use major: v180.0.0 = libbpf 1.8.0.

[d-e-s-o]

An alternative would be to only ever use major: v180.0.0 = libbpf 1.8.0.

I think one issue with that is that it forces us into incompatible changes. So far we've been lucky (or ignorant) and this is the first bump to cause trouble. So if we go with a major number representation we'd have a lot of incompatible releases for no real reason, would be my worry.
Basically, I think we are back at just simply decoupling libbpf-sys version from libbpf version. The latter is appended anyway. So next one could be v2.0.0+v1.8.0. Seems cleaner to me, to be honest.