Initially the RouteAdvertisements controller will use raw configuration for EVPN. Once the FRR-K8s API is ready, change the controller to use that API.

There can be the potential need to do some refactoring in the RouteAdvertisements controller for code clarity and maintainability. Before EVPN every FRRConfiguraton was processed independently. EVPN changed that because before generating an IPVRF router from a global router we need to know if that IPVRF is already defined in any FRRConfiguration. This required us to "look ahead" or do "two passes" on all FRRConfiguratons. While the level of complexity added is manageable right now, this can become messy quickly. It seems a more reasonable approach would be to process a collection of routers indexed by VRF keeping track of what FRRConfiguration defines them and then just generate the needed routers from that collection and then coalescing all generated routers to a single FRRConfiguration if possible (which will bring a performance improvement as well) or alternatively to new FRRConfigurations as done today. This is an optional consideration but moving to the official FRR-K8s API might be easier with this approach as well.