As it turns out Cargo now allows us to define certain Cargo meta-data in
a workspace-wide manner and then more easily reuse that. We intend to
update things such as the edition for all crates in the workspace and
the version of the two crates being published from the repository should
always be kept in sync. This makes those properties (and others) perfect
candidates for this infrastructure.
With this change we switch over to using workspace-wide properties for a
bunch of meta-data.

Signed-off-by: Daniel Müller <deso@posteo.net>

Bumps [serde](https://github.com/serde-rs/serde) from 1.0.208 to 1.0.209.
- [Release notes](https://github.com/serde-rs/serde/releases)
- [Commits](serde-rs/serde@v1.0.208...v1.0.209)

---
updated-dependencies:
- dependency-name: serde
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

After a eBPF program is loaded to the kernel and the loader process exited,
a user still may want to attach this program to PROG_ARRAY of another one.
Add an API to recover the file descriptor from a pinned path.

Signed-off-by: Ivan Koveshnikov <ikoveshnik@gmail.com>

Use a proper temporary file inside the object_type_from_fd() test,
instead of relying on the temporary directory being /tmp/ and hard coding
that fact.

Signed-off-by: Daniel Müller <deso@posteo.net>

Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.125 to 1.0.127.
- [Release notes](https://github.com/serde-rs/json/releases)
- [Commits](serde-rs/json@1.0.125...1.0.127)

---
updated-dependencies:
- dependency-name: serde_json
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

In the logic we generate for opening the skeleton, we unconditionally
work with some bpf_object_open_opts object, even if the user did not
customize anything. That's fine in principle, but it can trigger a bug
when a old system libbpf is used and which violates its forward
compatibility guarantees.
With this change we work around the issue by invoking
the bpf_object__open_skeleton() libbpf function with a NULL pointer if
SkelBuilder::open() instead of SkelBuilder::open_opts() is being used.
This is generally the common case and so we work around the underlying
libbpf bug until fixed and new releases rolled out to various
distributions.

Closes: #927

Signed-off-by: Daniel Müller <deso@posteo.net>

Prepare for release of 0.24.4 by bumping both libbpf-rs and libbpf-cargo
versions accordingly.

Signed-off-by: Daniel Müller <deso@posteo.net>