This patch introduces modification to AirPlay attributes allowing AirPlay clients
seeing only appropriate Endpoints of specific version of AirPlay protocol.
[Test]
Run two instances of shairport-sync - built for version 1 and for version 2.
TuneBlade recognizes only AirPlay version 1 instance running.
MacOS/iOS recognizes only AirPlay version 2 instance running.
Without that patch, both MacOS/iOS detect two endpoints at the same time.
The TuneBlade detects only AirPlay version 1 since it doesn't support AirPlay version 2.
Update to 4.3.2
**Enhancements**
* A totally new PipeWire backend featuring full synchronisation.
**Bug Fixes**
* Stability improvements for the PulseAudio backend.
* Fix a crash when the Avahi subsystem became disconnected. This is normally a rare occurrence, but Shairport Sync was not dereferencing obsolete data correctly when it happened.
* Set and reset Bonjour flags correctly when it's a Classic Airplay session in AirPlay 2 operation.
* Fix a number of FreeBSD compilation errors and warnings.
* Fix various errors when breaking into an existing session to terminate it. Thanks again to [aaronk6](https://github.com/aaronk6).
* Fix some debug message errors, sigh. Thanks to [Nathan Gray](https://github.com/n8gray).
This usually means there are problems in the system as a whole rahter than with Shairport Sync.
However, Shairport Sync was not cleaning up properly before deleting the now-disconnected avahi client and
creating a new one in an attempt to reconnect. That caused Shairport Sync to crash even if the new avahi client
was created successfully.
So this commit has code to delete the avahi group and broswer callback before deleting the disconnected avahi client.
to NULL and cleans up the bonjour flags, if appropriate.
Simplify the TEARDOWN handlers and the thress teardown functions by incporporating
the above code in the teardown_phase_two (for AP2) and teardown (fpr AP1) functions.
It means that closing a connection will block on the principal_conn_lock, so if
you have the principal_conn_lock, closing will not complete until you release it.
Maybe we need a principal_conn_acquisition_lock for that...