BMP rework - 2 BMP fixes + some rework

[pguibert6WIND]

A separate pull request will be put in place to add the following in BMP:

• ability to import BMP information from a separate BGP instance.
  This will be useful for L3VPN setups.

• Some commits prepare the code for to this feature. It includes the ability to share the bgpbmp structure for various usages

• A commit to re-send post-policy BGP updates when nexthop reachability is changed.

• A commit related to an ASAN issue encountered with rx_open and tx_open buffers.

[mjstapp]

so just making the general comment that we have historically done a poor job with refcounting. I think it would be much better to get an understanding of the goal, the proposal that you think requires refcounting, before taking such a change.

[mjstapp]

so ... won't this deref?

[pguibert6WIND]

if you have a better design pattern to apply to my use case, you are welcome:
I can try to apply it.

For the reason why I do this:

It is wishable to share the bmpbgp structure with a
separate BGP instance (lets say Y) that wants to import
the BMP information from X.

[mjstapp]

That may be a reasonable question, I guess, but it's not a response to the review comment? The review comment is "this code is wrong".
The irony is that the general comment was "this implementation choice is hard to get right", and ... in fact it's not right, even in this first effort.

[ton31337]

LGTM, waiting still on Mark's comment.

[mjstapp]

So some ideas about this:

For the reason why I do this:

It is wishable to share the bmpbgp structure with a
separate BGP instance (lets say Y) that wants to import
the BMP information from X.

I'm not sure I understand what "share the bmp structure" means. Do you want to share configuration - from parent to children, that sort of thing? or do you want to use a single bmp connection to multiplex updates from multiple bgp instances?

One choice would be to have X know about the set of its children or dependents {Y, A, B, ...} and push changes to those objects.
Another option might be to have the bmp instances in {Y, A, B, ...} refer to their parent in some other way - not be a pointer to their parent, but be able to locate their parent.

[pguibert6WIND]

So some ideas about this:

For the reason why I do this:

It is wishable to share the bmpbgp structure with a
separate BGP instance (lets say Y) that wants to import
the BMP information from X.

I'm not sure I understand what "share the bmp structure" means. Do you want to share configuration - from parent to children, that sort of thing? or do you want to use a single bmp connection to multiplex updates from multiple bgp instances?

Case one single BMP connection to multiplex updates from multiple bgp instances.

One choice would be to have X know about the set of its children or dependents {Y, A, B, ...} and push changes to those objects.

Not this choice.
The following vty command would be configured on BMP from Y.

router bgp 65500 vrf X
exit
router bgp 65500
  bmp target TGT1
   import-vrf-view vrf1
 exit
exit

Another option might be to have the bmp instances in {Y, A, B, ...}
refer to their parent in some other way - not be a pointer to their parent,
but be able to locate their parent.

Even if BMP from X is not configured, the instance Y needs to get access from it.
Reason to have this bgpbmp structure :

• it indicates the presence of a BGP instance.
• it stores the vrf presence (needed for loc-rib presence)

Either I reuse it, or I duplicate vrf_state in the imported list structure.

[pguibert6WIND]

I remove the lock idea.. closing this PR, creating new one: #17373

[ton31337]

Why not update this PR just?