Race condition in ReassignFlowPriorities due to missing synchronization on globalConjMatchFlowCache

[Ady0333]

Describe the bug
ReassignFlowPriorities modifies globalConjMatchFlowCache without holding conjMatchFlowLock.
This map is documented as lock-protected and every other code path that accesses it correctly acquires the lock, but this function does not.

Because of this, concurrent policy operations can access the map at the same time.

To Reproduce

1. The NetworkPolicy controller processes policy updates using multiple worker goroutines (see networkpolicy_controller.go, default worker count > 1).
2. One worker reconciles a policy update that triggers priority reassignment, calling:
   ReassignFlowPriorities() → updateConjunctionMatchFlows()
3. At the same time, another worker reconciles a different policy update (e.g. address or rule change), calling:
   InstallPolicyRuleFlows() or AddPolicyRuleAddress()
4. Both code paths access globalConjMatchFlowCache, but ReassignFlowPriorities does so without holding conjMatchFlowLock.

Under concurrent execution, this leads to unsynchronized access to the shared map.

Expected
All reads and writes to globalConjMatchFlowCache are synchronized using conjMatchFlowLock.

Actual behavior
updateConjunctionMatchFlows, called from ReassignFlowPriorities, performs deletes and writes on globalConjMatchFlowCache without holding the lock.
Under concurrency, this can lead to:

• Go runtime panics due to concurrent map access
• Inconsistent cache state
• Incorrect or unstable NetworkPolicy enforcement

Versions:

• Antrea version: affects current code (logic-level race, not version-specific)
• Kubernetes version: any
• Container runtime: any
• Linux kernel version: any
• OVS kernel module: any

Additional context
Affected code is in pkg/agent/openflow/network_policy.go.
All other functions accessing globalConjMatchFlowCache correctly acquire conjMatchFlowLock, making this issue isolated and easy to miss.