I’m looking at this issue now and, surprise, it seems mainline master (close to e241e3f2bf97) we are not leaking memory (or if so, far far less). I will post some quantitative data (start: 1.96GB memory used, after running for about 30 minutes: 2.17GB)
Also, super interesting fact is that my test loop:
sudo sh -c 'for i in $(seq 10000); do snap connect test-snapd-policy-app-consumer:bluez && snap disconnect test-snapd-policy-app-consumer:bluez; done'
Is actually not changing apparmor profiles. I took a snapshot of before/after and to my astonishment, noticed that they are identical (all profiles generated by snapd). Since apparmor_parser is not loading anything new into the kernel in this situation (AFAIK, I need to confirm this) this may indicate that the leak happens by merely observing the loaded profiles.
EDIT: due to the use of partial confinement on mainline kernels the relevant (DBus) apparmor rules were not generated. As such my test was inconclusive. I will now focus on a loop of just apparmor_parser with the disconnected/connected pair.