Use D-Bus library to communicate with NetworkManager and explicitly disconnect Wi-Fi

[applemayexist]

This MR:

• Uses libsystemd's D-Bus library to communicate with NetworkManager.
  • This avoids many syscalls from spawning nmcli processes, and those processes having to reconnect to D-Bus. Instead, we just keep one connection for the life of the wpa_supplicant process. Is this a hot path of the code? No, so it probably doesn't matter. But there's no reason I can't optimise it anyway!
  • More importantly, this is more direct communication with NetworkManager, so if nmcli isn't present, we can still know that NetworkManager is running and we can still tell it to stop managing our Wi-Fi adapter. Possibly useful for running in some sort of container that doesn't have NetworkManager installed, but does have access to the host D-Bus (though some polkit stuff would probably have to be figured out for that idk).
• Disconnects the Wi-Fi connection of the adapter we intend to use before unmanaging it. This way, iwd should not be an issue, and it avoids having to completely stop iwd (so it can still manage other adapters). This should close Support iwd #15. Also, save the connection and reconnect after remanaging the interface with NetworkManager.

Some current issues:

• NetworkManager seems to forget about disconnecting the interface if it receives a request to unmanage the interface right after the first request. I've fixed this by waiting for NetworkManager to confirm via signal that it has disconnected the device. However, there are still some issues I haven't figured out (it isn't reapplying the network config, why!?!!??!)
• During testing on a system with NetworkManager+iwd, this code failed to tell NetworkManager to remanage the network. This happened because I store the object path of the interface so we don't have to make another D-Bus call later on to figure out what the path is. However, during this testing, NetworkManager decided to move the interface to a new object path, hence invalidating the "cached" one. I'm guessing it did this because (due to the issue above) iwd and wpa_supplicant_drc were fighting to control the interface? Anyway, I'm assuming this isn't common (and shouldn't happen once I fix the above issue), so instead of just not remembering the object path, I'll make it check again if the call failed with the "cached" object path.

It's also important to mention that this code uses GCC's __attribute__((cleanup(x))), so that I don't have to remember to free memory, and forget a couple of paths bc I'm very lazy. Clang supports this as well of course. I hope this is not an issue, however I understand if it is and can rip it out.

[jacnils]

Is the systemd dependency this pull request would introduce really desirable though?

[applemayexist]

libelogind can be used in place of libsystemd

[applemayexist]

And it is not a requirement on systemd (the init system), just on its utility library. It can even be statically linked (though for whatever reason no distro builds the static lib).

[jacnils]

I apologize for the misinformation, I assumed the library was dependent on systemd itself.

[applemayexist]

I apologize for the misinformation, I assumed the library was dependent on systemd itself.

No problem! It's a reasonable assumption to make, but it just ain't so.

[itsmattkc]

This is obsoleted by 89f25ee