Changes

s1ap_proxy: use erab_uid() to log unique E-RAB ID

Change-Id: I89d8bedcd6acc1d8cdd6f56bf36ffa3001f2c8c2

s1ap_proxy: add a TODO about an optional IE

Change-Id: I3980ae86a61e59af5cec8e7138062cc72a6cd130

s1ap_proxy: rework handle_ie/2 into handle_ie/3

This patch prepares for a follow-up change adding E-RAB MODIFY REQ/RSP.

Instead of passing the whole record #'ProtocolIE-Field' to handle_ie(),
pass the IEI ('id' field) and IE content ('value' field) as separate
arguments.  This split-up allows to pass the full IEI path to
handle_ie() in a follow-up change, and also allows to expand some
fields of the IE content right in the function header.

Change-Id: Ic71c8c07739b0e354ca9c9b03c000a366d8c2c43

s1ap_proxy: handle_ies(): reorder arguments

This patch prepares for a follow-up change adding E-RAB MODIFY REQ/RSP.

It's common for many Erlang's built-in functions to have the Key argument first
(e.g. dict:store/3, dict:take/2, proplists:lookup/2, proplists:delete/2),
and also makes handle_ies() consistent with handle_ie().

Change-Id: Ic9c7257bef290a7f0c2546d4c1ca3b9d4aed20d2

s1ap_proxy: handle_ies(): pass IEI path to handle_ie()

This patch prepares for a follow-up change adding E-RAB MODIFY REQ/RSP.

We need to be able to match the IEs unambiguously, because the same
IEI may be used in different contexts and thus have different meaning,
sometimes within the same PDU.  The E-RABItem IE is such an example:

* 9.1.3.5 E-RAB RELEASE COMMAND
** contains an E-RABToBeReleasedList IE
*** contains E-RABItem IEs

* 9.1.3.7 E-RAB RELEASE INDICATION
** contains an E-RABReleasedList IE
*** contains E-RABItem IEs

So far we handled this duality by passing the release kind via
the #proxy_state record ('rel_kind' field) and it worked.  But
soon in follow-up changes we'll have to deal with other PDUs:

* 9.1.3.4 E-RAB MODIFY RESPONSE
** contains an E-RABModifyListBearerModRes IE
** may contain an E-RABFailedToModifyList IE
*** contains E-RABItem IEs

* 9.1.3.9 E-RAB MODIFICATION CONFIRM
** may contain an E-RABFailedToModifyList IE
*** contains E-RABItem IEs
** may contain an E-RABToBeReleased IE
*** contains E-RABItem IEs

A universal approach allowing to match and handle IEs properly
depending on the context is to maintain the full IEI path
in handle_ies() and pass it to handle_ie().

Change-Id: I35528a91f7dbf321ad1a0811f1bbcdfb529d3530

s1ap_proxy: handle_ies(): also handle #'ProtocolExtensionField'

This patch prepares for a follow-up change adding E-RAB MODIFY REQ/RSP,
allowing to execute handle_ies() on a list of #'ProtocolExtensionField'.

* 9.1.3.3 E-RAB MODIFY REQUEST
** contains an E-RABToBeModifiedListBearerModReq IE
*** contains E-RABToBeModifiedItemBearerModReq IEs
**** each may optionally contain TransportInformation IE
                                 ^^^^^^^^^^^^^^^^^^^^^^^
                                 #'ProtocolExtensionField'

Change-Id: Ic1ed2c4662e82bd739c35f9179eaaec20c3cad98

erab_fsm: store UID, expose it via fetch_info/1

Change-Id: I63fbd1d3d3531a74b35c09345cec094c30d19356

erab_fsm: session_modify(): split PFCP PDU handling

This patch prepares for a follow-up change adding the MME-initiated
E-RAB modification logic.  Handle the successful modification scenario
in a separate function, which will be extended further soon.

Change-Id: I04fec627300fa9240e6b2bf22ff9ae08dd4c0f0d