feat: add F-TEID allocation support

[gruyaume]

Description

As of 3GPP Release 16, F-TEID allocation is done in the UPF instead of the SMF. This PR implements F-TEID allocation as well as the necessary PFCP communication changes.

Summary

1. Addition of a enable_ftup configuration option that users can set to decide whether or not they want the UPF the allocate F-TEID's
2. Based on the previous option, the UPF will set the FTUP feature flag in its PFCP Association Setup Response to the SMF
3. The SMF must set the CHOOSE flag in its request to establishment a new PDR in the PFCP Session Establishment Request
4. When this CHOOSE flag is set, the UPF allocates a F-TEID using a TEID generator
5. The UPF sets
   the F-TEID in its PFCP Session Establishment Response

Changes in the SMF and UPF are intertwined

This change and the SMF are intertwined and have to be merged close together so that the network keeps on working on main:

• feat: request UPF to allocate F-TEID  smf#334

After this PR is merged

[UPF] Reject PFCP Session Establishment Requests if the SMF allocated an F-TEID with the cause "Invalid F-TEID allocation option".

Reference

3GPP Release 16

Relevant information from the 3GPP Release 16 29.244 document:

F-TEID shall be only allocated by the UPF. The UPF shall set the FTUP feature flag in the UP Function Features IE and the SMF shall request the UPF to allocate the F-TEID. The UPF shall reject a request to establish a new PDR with
an F-TEID allocation in the SMF option, with the cause "Invalid F-TEID allocation option". As an exception, the
UPF shall accept the PFCP Session Establishment Request message with a PDR including an existing F-TEID
to re-establish a PFCP session during a restoration procedure.

The SMF shall request the UPF to allocate the F-TEID by setting the CHOOSE flag in the Local F-TEID. And if the PDR(s) is created successfully, the UPF shall return the F-TEID(s) it has assigned to the PDR(s) in the PFCP Session Establishment Response or PFCP Session Modification Response.

• 3GPP Release 16: Interface between the Control Plane and the User Plane nodes

[omecproject]

Can one of the admins verify this patch?

[gab-arrobo]

@gruyaume please rebase your PR.

[gab-arrobo]

@gruyaume,
FYI, the 2 GHAs that fail are because of the same reason:

=== RUN   TestUPFBasedUeIPAllocation
    basic_test.go:102: 
        	Error Trace:	/home/runner/work/upf/upf/test/integration/basic_test.go:102
        	Error:      	"[0xc000de20c0 0xc000de2180]" should have 1 item(s), but has 2
        	Test:       	TestUPFBasedUeIPAllocation
--- FAIL: TestUPFBasedUeIPAllocation (5.18s)

[gruyaume]

@gruyaume, FYI, the 2 GHAs that fail are because of the same reason:

=== RUN   TestUPFBasedUeIPAllocation
    basic_test.go:102: 
        	Error Trace:	/home/runner/work/upf/upf/test/integration/basic_test.go:102
        	Error:      	"[0xc000de20c0 0xc000de2180]" should have 1 item(s), but has 2
        	Test:       	TestUPFBasedUeIPAllocation
--- FAIL: TestUPFBasedUeIPAllocation (5.18s)

Yeah this is still a draft, I'm trying to figure out why the Created PDR's aren't returned in the PFCP Session Establishment Response.