tests: Add a topology that shows broken ibgp behavior

tests: Add a topology that shows broken ibgp behavior

In a leaf/spine topology with only IBGP connections, where
the same network is being redistributed at multiple points
in the network ( say a redistribute connected at both leaf and spines )
we end up in a state where zebra gets very confused.

eva# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

C>* 192.168.1.0/24 is directly connected, tor1-eth0, 00:00:30
C>* 192.168.2.0/24 is directly connected, tor1-eth1, 00:00:30
B   192.168.3.0/24 [200/0] via 192.168.4.2 inactive, 00:00:25
                           via 192.168.6.2 inactive, 00:00:25
B>* 192.168.4.0/24 [200/0] via 192.168.2.3, tor1-eth1, 00:00:25
  *                        via 192.168.6.2 inactive, 00:00:25
C>* 192.168.5.0/24 is directly connected, tor1-eth2, 00:00:30
B>* 192.168.6.0/24 [200/0] via 192.168.4.2 inactive, 00:00:25
  *                        via 192.168.5.4, tor1-eth2, 00:00:25

Effectively we have ibgp routes recursing through ibgp routes
and there is no metric to discern whom to listen to.

This draft:
https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-19

appears to address this issue.  From looking at both cisco and arista
deployments they are handling this issue by having the route reflector
prefer the localy learned routes over from their clients.

Add this topology, in a broken state, so that when we do fix this issue
it is a simple matter of touching this topology up and re-adding it
to the normal daily builds.  I also wanted to add this topology
since it is in a state of `doneness` and I wanted to move onto
my normal day job without having to remember about this test.

This topology is not configured to be run as part of the normal
topotests.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>