NetApp: set real ifgroup MAC on Neutron ports for consistency

[skook1]

NetApp LIFs do not have their own MAC - they inherit from the underlying ifgroup. Manila creates a Neutron port per share server, but never set the MAC, leaving it as a random Neutron-generated value that does not match what appears on the wire. This caused MAC mismatch warnings in hammer net check.

Approach:

• On allocate_network, fetch the real ifgroup MAC of the first cluster node and pass it to the Neutron port create call
• On MacAddressInUse (409), retry the create without the MAC
• Sync the real per-node LIF MACs into Manila's network_allocations DB after LIF creation, so Manila's own view is always correct regardless of what ended up on the Neutron port

Neutron enforces UniqueConstraint(network_id, mac_address) in our fork, so the overflow case (2nd+ share server on the same network+filer) always falls back to the description path - this is expected and matches the plan.

Limitations from Neutron fork:
SAP's Neutron makes MAC uniqueness global (deployment-wide) on port create, motivated by Cisco IOS XE dropping frames on MAC collision regardless of VRF. This means the very first port for a given filer succeeds anywhere in the deployment, but every subsequent share server on that filer - across any network, any project - hits 409 and falls through to the fallback path.

Change-Id: I17464f0d3300e86f26172242f12453397972bf4a
Signed-off-by: Nikita Skakun nikita.skakun@sap.com

[skook1]

issue - https://github.wdf.sap.corp/sap-cloud-infrastructure/manila-issues/issues/79
the way that was described in the ticket is not a good way for us, because

`I investigated the proposed Maurice approach and unfortunately it doesn't work in our environment for a few reasons, If I correctly understand your idea:
The network allocations table is storing the mac, too. So we could: assign a certain mac when we do neutron port create.
And later when we do lif create, we could match the mac from the network allocation taken from manila db with the mac from the node again.

E.g. we know upfront: NODE-1 has MAC1, NODE-2 has MAC2, then we randomly create two PORTS, PORT-A with MAC1, PORT-B with MAC2. And when it comes to create LIF-1 on NODE-1 we know that NODE-1 has MAC1 and therefore know that we need to take PORT-A no matter the orderingThe core issue is that on NetApp, all LIFs on the same node share the same physical mac. This means if a project has multiple share servers on the same node, all their LIFs will have identical macs. Since Neutron enforces mac uniqueness per network, creating a second port with that same MAC would immediately fail with:
 mac address is in use (already tested that in qa-de-1).
So the pre-assignment idea breaks down as soon as you have more than one share server per node.`

another way to resolve that was implemented in this PR - https://convergedcloud.slack.com/archives/CAVMRU0BB/p1782392305187009