Simplify & improve OS completeName determination

[chadlwilson]

This change replaces the Python+direct file reading hack for determining a "complete" OS family names with a more modern cross-platform library (oshi) that does the same. The library has ability to use native code to get a LOT more information out from the underlying OS than is being used here.

The hack was introduced in #2421 despite some of the initial objections (as to shelling out with Python, here), reverted, and then reintroduced in #2608 eventually. The attempt to shell out to Python happens regardless of OS, and I'm not sure it does any better than reading the name from /etc/os-release anyway.

This change also

• moves the logic back to the agent lib, to avoid dependencies propagating everywhere. Only the agent needs this logic.

Some examples (before --> after)

Basically the same (linuxes)

• Alpine Linux v3.17 --> Alpine Linux 3.17.1
• Ubuntu 22.04.1 LTS --> Ubuntu 22.04.1 LTS (Jammy Jellyfish)
• CentOS Stream 9 --> CentOS Stream 9
• Debian GNU/Linux 11 (bullseye)--> Debian GNU/Linux 11 (bullseye)
• Windows 11 --> Windows 11

Enhanced (non-linuxes)

• Mac OS X --> macOS 13.1 (Ventura)
• Windows Server 2022 --> Windows Server 2022 (Datacenter)

It also adds support for many others, so is far is less opinionated than before.

Task list

• Prefix with manufacturer? (Linux, GNU/Linux, Apple, Microsoft etc)
  • The existing ones don't have a "manufacturer name" so let's leave it for now
• Verify fallback behaviour of OSHI if can't determine at least the family + version

[chadlwilson]

Any input from Mr @ketan here would also be appreciated :-)

[ketan]

I remember seeing this library, but was not as evolved/matured at the time. The reason OperatingSystem.java exists in its current shape and form is to ensure that it always returns some "sensible" OS name and prevents startup failure. As long as you're able to prevent that startup failure, and checks most popular linux distros, go for it.

[ketan]

Also, I've not seen the code — but I'd make sure to "cache" the value, so as to not evaluate the OS version on every method invocation, mostly to avoid any expensive shelling out or file reading this library might be doing under the hood.

[chadlwilson]

Thanks - yeah it caches the value. I'll double check the behaviour if the library can't read the value for some reason for a given distro/OS. (edit: added a fallback)

[arvindsv]

Looks good to me. The SystemInfoTest is the one I was worried about -- as not being future proof, and whether we needed such a strict regex to verify it. But, it's unlikely to change too quickly. Should be ok.

Also, TIL about !! used in build.gradle (gradle doc)

[chadlwilson]

Also, TIL about !! used in build.gradle (gradle doc)

Probably would be better to use the more descriptive version than the magic. (edit: fixed)

The OSHI library depends on slf4j APi 2.x and it causes an implicit upgrade where which has some other problems I haven't been able to workaround yet with respect to the way we use classloaders within the agent and launcher. Their usage should still work with SLF4J 1.7.x as far as I can tell since it is largely API compatible.