Provide mechanism to protect from orphaning LBaaSv2 haproxy instances when relating to octavia

[Drew Freiberger]

When an operator relates octavia to neutron-api as is part of the documented process, it changes the service_provider from lbaasv2 to lbaasv2-proxy in neutron.conf on the neutron-api servers.

It would be helpful to have a sanity check that there are no running haproxy loadbalancers under the to-be-orphaned lbaasv2 haproxy agents on neutron-gateway nodes before performing this irreversible change, or provide a method on neutron-loadbalancer-plugin-relation-departed/broken to revert the API back to configuration that allows for managing the haproxy instances.

Documentation of how to manage/decommission haproxy instances after adding the octavia->neutron-api relation would be very helpful for those who have already stepped past the warning on the charm-guide to not make this relation.

I do see that the haproxy instances are still running, they're just not able to be managed or introspected either via api or horizon which makes migration to octavia difficult.