bluetooth: Perform software attenuation until HF/HS reports gain control

Depends on !519 (merged)

HF/HS hardware attenuation is optional on HFP: the peer indicates support with the AT+BRSF command, when bit 4 is set. That only mandates speaker gain control; microphone gain support is signaled later by sending initial microphone gain with AT+VGM=. Otherwise software attenuation is performed.

It is also optional on HSP but nothing is mentioned about feature detection, assume it is the same as HFP microphone gain detection: perform software attenuation until the HF/HS peer reports AT+VGM/AT+VGS.

When PA is a HS/HF (and the peer the AG) we attenuate both channels in software and unconditionally keep the peer up to date with AT+VGM/AT+VGS commands.

---

@igor.v.kovalenko this is my take on MarijnS95/pulseaudio!2 (closed) in accordance with !239 (merged). Notable differences:

• No extra booleans or callbacks, support is solely expressed by the existing set_{sink,source}_volume callbacks being NULL or containing a valid function pointer;
• Rather than checking for support when sending a notification in {sink,source}_process_msg which is safe to happen unconditionally, this MR checks for support before hooking up hardware callbacks (only when PA is the AG) for which the reasoning is fully covered by !519 (merged).

TODO:

• Import changes like command parsing logic from https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-September/028820.html, probably by rebasing your patch on top of this MR;
• Checking whether AT+BRSF= and AT+VG[MS]= is always received before sinks and sources are created. Otherwise we will have to dynamically attach the callbacks when these commands are received;
• Add more assertions that we're in the right profile when receiving certain commands, and that the peer isn't messing with us.
  • For example: we shouldn't receive AT+VGS in HFP unless the relevant bit was set.