Refactor SMF PFCP associations to always use UPF info

Logical changes

• Each UPF has now a UPF profile associated
• in case there is no UPF profile (not in config or UPF-initiated PFCP association): Create a default UPF profile with an assumed N3 and N6 interface
• Reason: We had many cases where we differentiate if upf profile is set, now we can delete all these checks
• Preparation for a further UPF graph / edge / QoS flow refactor

Fixes / Implements

• Implements #47 (closed)
• Implements #22 (closed) -> We can now have different UPF config (e.g. enable URR and disable) for different UPFs. IN THEORY we could even run OAI-UPF, VPP-UPF and SD Fabric together
• Should implement #6 (closed) (@tien-thinh.nguyen can you confirm this?)
• UPF is now not resolved immediately upon SMF start, but we try it 10 times every 2 seconds
• Also SMF does not crash anymore if UPF could not be resolved, but just does not initiate a PFCP association
• @arora the last two changes are interesting for docker-compose and k8s -> It is much more stable now and the order of NFs is not that strict anymore

Refactorings

• regenerated NotificationData and associated model classes

  • will be moved to common-src in a further refactor (as they come from NRF)
  • use OpenAPI model class for noficationData within SMF

• Simplify handling of NF UPF notifcation and UPF assocation start a bit in smf_app

• Remove unnecessary code in smf_config.hpp

Tests

• wrote some tests for these changes, see: oai-cn5g-fed!146 (merged)