feat: include libyaml-dev for apt charm plug-in builds

[tonyandrewmeyer]

Operator framework charms will try to use the libyaml based PyYAML, which is significantly faster than the pure Python one. In an apt system, like Ubuntu, this requires libyaml-dev to build from source. If the libyaml dev files are not available, then the pure Python version will be built instead.

Charms can get the faster version by including libyaml-dev in the build-packages section of the metadata, or by allowing PyYAML as a binary package (the wheel has the faster version). However, this is fairly esoteric knowledge.

Since the charm plug-in is specifically for operator framework charms, and ops has PyYAML as a dependency so be required for every ops charm, it seems reasonable to have libyaml-dev as a build dependency, which means that everyone (on an apt-based system) will get the faster YAML processing for 'free'.

Detailed timing for setting relation data can be found using the example charm in this repo. Setting 4MB of relation data with the pure Python version takes around 2s, and with the libyaml version around 0.02s. This can be significant for some charms.

A complete test for this would be to do a basic charm build and verify that the .so file is included in the venv/yaml folder, but I wasn't sure whether that sort of test would be appropriate for charmcraft or not. Let me know if I should work on that, assuming that you're inclined to accept this change.

[tonyandrewmeyer]

One part of this that I didn't consider until today was that on more recent build images the system package (python3-yaml etc) is generally installed, and since charmcraft makes use of dist packages a requirement of 6.* (as ops currently specifies) would already be satisfied and charmcraft wouldn't build pyyaml at all. This should be the case with 24.04, for example. Similarly, in the past (Jan 2023 and prior) ops didn't pin pyyaml at all, and so assuming the distribution package was installed, would have just used whatever that had, and never built.

So we could achieve the same thing by having ops pin pyyaml differently (I'm not a huge fan of >5, but it would work, or we could tie it to the Python version even though that's not technically the case), or it could just be that you get "slow" pyyaml in 22.04 and "fast" pyyaml in 22.10 (and the same sort of thing with the Debian versions), at least until ops bumps the dependency higher than 22.10 has.

It does feel cleaner to me to have it available for building, and if there is a switch added to not use dist packages then this would protect against that. But something to consider.