fix(neutron-understack): VNI allocation behaviors

[cardoe]

Summary

Fixes VNI (VXLAN Network Identifier) allocation for routers so that VNIs are only allocated for flavors that actually want them, rather than for every router. This revisits a review comment @skrobul made on #2109 and closes the over-allocation leak introduced there.

Problem

Two issues caused every router — including non-VRF flavors like Palo Alto and Cisco ASA — to silently receive a VNI:

1. The evpn_vni router attribute defaulted to 0. Neutron core reads 0 as an auto-allocate request, so a bare router create triggered a VNI allocation.
2. The plugin decided whether to allocate based solely on whether the flavor's provider driver was Vrf. This is too coarse — it can't distinguish the "admin supplies a VNI" case from the "auto-allocate from a pool" case, and it can't cleanly opt other flavors out.

Changes

do not always allocate VNIs for all routers

• Change the evpn_vni attribute default from 0 to ATTR_NOT_SPECIFIED, so a bare router create no longer causes Neutron core to auto-allocate a VNI.

add VNI allocation flag to VNI service plugin

• Drive allocation from a vni_alloc key in the flavor's service-profile metainfo instead of from the provider driver name. Three modes:
  • off (default) — never allocate; reject an explicitly supplied evpn_vni.
  • on — allocate only an explicitly supplied VNI (used by static_vrf).
  • auto — auto-allocate from the pool when none is supplied (used by dynamic_vrf).
• This lets dynamic_vrf and static_vrf share the same Vrf provider driver while differing only in service-profile metainfo. Any flavor with no metainfo, an invalid value, or no flavor at all safely defaults to off.
• Invalid/non-JSON metainfo is logged and falls back to off.
• Add operator and design-guide documentation covering router flavors, the vni_alloc toggle, the auto-allocation pool ([understack_vni] vni_ranges), configuration/migration steps, and troubleshooting.

Testing

• Expanded test_understack_vni.py to cover all three modes (with and without a supplied VNI), missing metainfo, no flavor, invalid mode, and the ATTR_NOT_SPECIFIED default guard.

Notes / migration

vni_alloc lives on the service profile, not the flavor. Because dynamic_vrf and static_vrf need different values, they must be bound to separate service profiles even though both use the Vrf driver — see the operator guide for the rebind steps.

[mfencik]

LGTM