bagpipe driver: wrong RTs passed to agent on BGPVPN update or association updates in the case of multiple associations

[Thomas Morin]

The following seems to not be addressed in the bagpipe driver in the case where multiple associations are made between a Network and multiple BGPVPNs.

Updating a said BGPVPN (BGPVPN A):
- what is done now: for all the networks N associated with BGPVPN A send an RPC for Network N with updated RTs based only on BGPVPN A
- what should be done: send updated RTs based on all the BGPVPNs to which network N is associated

Deleting a said BGPVPN (BGPVPN A):
- what is done now: send an RPC for Network N with no RTs
- what should be done: send updated RTs based on all the BGPVPNs to which network N is associated (excluding the BGVPN that was just deleted)

Creating a said association between BGPVPN A and network N:
- what is done now: send an RPC for Network N with updated RTs based only on BGPVPN A
- what should be done: send updated RTs based on all the BGPVPNs to which network N is now associated

Deleting a said association between BGPVPN A and network N:
- what is done now: send an RPC for Network N with no RTs
- what should be done: send updated RTs based on all the BGPVPNs to which network N is now associated

A related issue is that the create_bgpvpn, delete_bgpvpn, and update_bgpvpn RPCs are:
- misnamed (they are related to a network)
- duplicated, it seems we only need 'update'
Renaming them would be ideal, but requires coordinated changes between networking-bgpvpn and networking-bagpipe.
We should at least document them better, and mark the useless ones as obsolete.

[Thomas Morin (tmmorin-orange)]

Importance 'medium' because multiple associations between a network and a BGPVPN is not the most critical use case.

[Thomas Morin (tmmorin-orange)]

Fixed in Queens, thanks to moving to OVO-based RPCs.