refactor(server): introduce receiver interface and drive filterpath from it

[Ivan-Pokhabov]

Add peerPathLimiter and receiver interfaces that abstract a BGP peer (or
future peer-group) for the purpose of export-path filtering and policy
application. Refactor filterpath, prePolicyFilterpath, postFilterpath,
getPossibleBest, sendSecondaryRoutes and processOutgoingPaths to accept
receiver instead of *peer. Split the old filterpath into peerFilterpath
(peer-specific RF, RTC and source-peer checks) and a generic filterpath
that works over any receiver. No behaviour change for existing peer-only paths.

Co-Authored-By: Ivan-Pokhabov vanek3372@gmail.com

Part of #3161

[Ivan-Pokhabov]

@fujita, can you check this also, please? It would help to add perfomance feature for route-reflector #3161. Thanks in advance.

[fujita]

I'm not sure about the approach of #3161.

Policy sharing should be automatic rather than an explicit flag — peers with identical effective policies should be grouped automatically, and any peer with a per-peer-sensitive condition (such as a NeighborSet matching on destination address) should fall back to per-peer evaluation transparently.

[Ivan-Pokhabov]

I'm not sure about the approach of #3161.

Policy sharing should be automatic rather than an explicit flag — peers with identical effective policies should be grouped automatically, and any peer with a per-peer-sensitive condition (such as a NeighborSet matching on destination address) should fall back to per-peer evaluation transparently.

Ok, I will think about design, but this PR doesn't interfere this optimization in my opinion

[fujita]

I'm not sure about the approach of #3161.
Policy sharing should be automatic rather than an explicit flag — peers with identical effective policies should be grouped automatically, and any peer with a per-peer-sensitive condition (such as a NeighborSet matching on destination address) should fall back to per-peer evaluation transparently.

Ok, I will think about design, but this PR doesn't interfere this optimization in my opinion

I don't that this abstraction is necessary if that pull request isn't merged.

[Ivan-Pokhabov]

I don't that this abstraction is necessary if that pull request isn't merged.

Ok, thank you, I will come back with new design