BGP peer groups vs port names

Applying a new BGP config requires maps of numbered and unnumbered peers keyed by "peer group": https://github.com/oxidecomputer/maghemite/blob/a31a86e297ea593f5bbff5be40a7faffbb3ca0d9/mg-api-types/versions/src/bgp_src_addr/bgp/config.rs#L118-L122

After a brief chat with @taspelund (but if there are any incorrect bits here, it's definitely my lack of context), my understanding is that a peer group in the BGP sense is a set of BGP peer configs that share some common settings. But:

• That isn't consistent with the shape of this API; each item in the maps' values' Vecs contains a full set of configuration that can be entirely different from other configs in the same vec
• Nexus doesn't have a concept of peer groups at all; it builds these maps by using the switch port name as the keys:
  • https://github.com/oxidecomputer/omicron/blob/ff546dc31ec35a9d336d66f00cb60707bfa4cd6d/nexus/src/app/background/tasks/sync_switch_configuration.rs#L550-L552
  • https://github.com/oxidecomputer/omicron/blob/ff546dc31ec35a9d336d66f00cb60707bfa4cd6d/nexus/src/app/background/tasks/sync_switch_configuration.rs#L858
  • https://github.com/oxidecomputer/omicron/blob/ff546dc31ec35a9d336d66f00cb60707bfa4cd6d/nexus/src/app/background/tasks/sync_switch_configuration.rs#L909

Would Nexus be just as correct to send a HashMap with a single (arbitrary) key and all the configs in a single Vec value? If so, would it make sense to squish this API down to Vec<_>s instead of HashMap<String, Vec<_>>s?

Read mg-api-types/versions/src/bgp_src_addr/bgp/config.rs around lines 118-122, then compare the callers in Nexus at sync_switch_configuration.rs lines 550-552, 858, and 909. Determine whether the map keys carry required BGP semantics or only port names; done means documenting the decision and, if an API change is approved, updating the affected callers and validation.