Speed up RTC exchange, exclude non-VPN paths from the RTC scheme

[bor1go]

1. Add Key(RouteTarget)->uint64.
2. Add map[Key(rt)]map[*Path]{} to globalRib VPN tables for fast making path list by RT.
3. Add map[Key(rt)]int to Adj RTC tables for fast filtering paths by RTs.
4. Add tests on pp.1-3.
5. Non-VPN paths must not depend on RTC.

This is about complexity of RTC.

1. Currently, filtering a single VPN path before sending requires O(n) operations, where n is the number of RTs in the RF_RTC_UC table. Constructing a list of VPNs takes O(nm) operations, where m is the number of VPN paths (filterpath).
2. When a new RT is received, filtering VPNs to respond (propagateUpdate) requires O(m) operations.

This PR proposes a new approach that potentially reduces the complexity to O(1) for filtering and retrieving VPN paths, assuming the map container is used effectively. However, this approach requires additional memory. Specifically, for each VPN GRT, it necessitates:
n*L*m*sizeof(*Path) , where L is the average number of extRTs in the Path, m - number of paths, n - number of known RTs +
n*sizeof(RouterID) - to store interested on RT peers +
n*sizeof(uint64) - for indexing RTs
Additionally, for each Adj RF_RTC_UC table, the memory requirement is approximately:
n*(sizeof(uint64)+sizeof(int))

[bor1go]

@fujita could you please take a look at it, if it is possible?
I attempted to optimize the RTC by reducing linear and quadratic complexity for large numbers of paths.

[fujita]

Specifically, for each VPN GRT, it necessitates

What' VPN GRT?

[bor1go]

What' VPN GRT?

I meant global rib tables for VPN families.

[bor1go]

@fujita could you take a look at it again, please?
This approach could be helpful with big numbers of routes and route targets.

[bor1go]

I made some changes: the approach that distinguished between VPN and non-VPN families was wrong.

Now all families are could be use in the RTC scheme. And current PR:

1. Adds Key(RouteTarget)->uint64.
2. Adds map[Key(rt)]map[*Path]{} to globalRib tables for fast making path list by RT.
3. Adds map[Key(rt)]int to Adj RTC tables for fast filtering paths by RTs.
4. Adds tests on pp.1-3.

[bor1go]

Hello, @fujita ,
Could you approve a workflow please? I've tested it locally, but it would be better to check it here...

[bor1go]

Hello, @fujita ,
May I kindly remind you about this PR?

When a large number of RTs are loaded into GoBGP, the RTC filter becomes dramatically slow. I measured the performance on two GoBGPs running on the same PC. I loaded paths on one server and RTs on another, then established peering.

For example, if we have 10 paths with the same RT:

• For 1,000 RTs: filtering speed is about 100,000 paths in a few seconds
• For 5,000 RTs: 100,000 paths in 600 seconds
• For 10,000 RTs: 100,000 paths in 1,300 seconds
• For 100,000 RTs: 100,000 paths in approximately 20,000 seconds (I didn’t wait for it to finish)

The performance depends on the average number of paths per RT and the total number of RTs.

I modified the filter process to use maps instead of nested loops. Now it works much faster, with O(1) complexity instead of O(nm).

We are using this change in our environment and have not encountered any issues in this code so far.