Thanks for the reply. I think it is becoming clearer now.
Where exactly can I find the latest nmcli binary to download and include in my snap?
As far as I understand in the example from the wifi-ap snap you are also not building it but using the binary.
If I do the same then I could invoke it using my-snap-name.nmcli ?
I am not sure if I understand what you want to ask. But let me try to answer what I understand. You can’t call /snap/bin/network-manager.nmcli as this is owned by the network-manager snap. No interface will allow you to use something out of /snap/bin. The a plug of the network-manager interface will only allow you to talk to the NetworkManager service coming from the network-manager snap over dbus, nothing else.
Normally we don’t want to use explicit deny rules because deny rules are always evaluated after allow rules (ie, another allow rule can’t undo it), but in this case the rule is very specific-- the network-manager slot is not allowed to ptrace trace connected plugs.
apparmor=ALLOWED indicates that your devmode snap is doing something that is a violation of sandbox policy, but because you are in devmode it is only logged, not DENIED. Most of the time this will indicate a problem when you put your snap in strict mode (I say most of the time because software may exercise different code paths when under confinement depending on how it handles denials, etc).
This indicates you are calling systemctl and this is not supported by any interface (because of systemd’s current design it is unconfineable. Ie, the policy quickly spins out to you can interfere with the system or other snaps). Why are you using systemctl? Perhaps there is another way to achive your goal.
Also note that systemd uses DBus quite a bit, so be sure also to look at the raw logs (sudo journalctl) to see DBus violations of policy that might indicate what your snap is trying to do if you aren’t calling systemctl explicitly.