UPF pod crash occurring during UE attachment

[bhagathkrishnacdac]

Issue/Feature Description:
Fix UPF pod crash occurring during UE (User Equipment) attachment when the flow_measure module is enabled.

Why this issue to fixed / feature is needed(give scenarios or use cases):

When the measure_flow option is enabled in the UPF configuration, the system is designed to track per-flow QoS metrics as UEs connect and generate traffic.
In the previous implementation, the UPF pod would intermittently crash during the UE attachment phase. This was likely caused by:

1. Fixed-Size Hash Table Limits: The DPDK rte_hash used a pre-allocated size. Rapid attachment of many UEs could exhaust the table or lead to insertion failures that weren't handled gracefully.
2. Race Conditions: Under high-concurrency scenarios (multiple UEs connecting simultaneously), the locking mechanism in the original module was insufficient to protect the hash table and the statistics vector during rapid session creation and control-plane "read/flip" operations.
3. Pointer Invalidation: Using a fixed-size vector to store statistics meant that any mismatch between the hash index and the vector bounds would lead to a segmentation fault.

This refactor replaces the rigid DPDK structures with dynamic C++ containers and a shared-mutex strategy to ensure the UPF remains stable during high-churn UE attachment events.

How to reproduce, in case of a bug:

1. Deploy the UPF with the flow_measure (qos_measure) module enabled in the pipeline.
2. Trigger multiple UE attachment procedures (e.g., using a RAN emulator like gNBSim or real UEs).
3. Observe the UPF pod logs; the pod would crash with a segmentation fault or a BESS core dump shortly after traffic begins to flow for the newly created sessions.

Other Notes / Environment Information: (Please give the env information, log link or any useful information for this issue)