sgsn: Prevent memory leak and double free

This has been re-produced using the "osmo-pcu emulator" code
and a ping to force segmented SNDCP messages. When the NS link
enters the DEAD/BLOCKED state the msgb would be freed twice.
Once inside gprs_ns_sendmsg and once by the caller. Based on the
return one can not see if the parameter has been deleted.

I changed libosmocore/libosmogb to always free the msgb in case
of an error on the way to gprs_ns_sendmsg. Catch up, avoid the
double free and fix some memory leaks. In case the sending fails
assume the entire segmented message is at end and free the
original input data.

This has been tested by posix suspending/resuming the emulator
process to have the GPRS-NS link go to dead/blocked to alive
and unblocked. The ping recovers and "SIGUSR1" to the SGSN does
not show active memory allocations.

The SGSN calls bssgp_tx_dl_ud at the lowest level and has the
following callchains. Most of them allocate the msgb and have
no early return and transfer ownership already:

<- gprs_llc_tx_u
<- gprs_llc_tx_ui
	<- gsm48_gmm_sendmsg (all callers sane)
		<- _tx_status
		<- _tx_detach_req
	<- gprs_llc_tx_xid (all callers sane)
	<- sndcp_unitdata_req
		<- sndcp_send_ud_frag
gbproxy: Discard UL PTP messages with an unknown BVCI

Currently all PTP messages are in general forwarded to the SGSN even
when the BVCI is not known to the gbproxy. Only if message patching
is active and the peer cannot be determined, a log message is
generated, a STATUS message returned, and the message discarded.
The intention for this was to keep the old gbproxy's behaviour if
patching is disabled. But the code gets much more complex this way.
Another drawback is that when the SGSN returns a corresponding STATUS
message, it cannot be routed to the BSS where the original message
came from.

This patch therefore changes the behaviour to reject BSSGP PTP uplink
messages immediately if the BVCI is not known.

Fixes: Coverity CID 1244240
Ticket: OW#1317
Sponsored-by: On-Waves ehf
gbproxy/test: Don't assign a variable within OSMO_ASSERT (Coverity)

Coverity complains about having side effects in OSMO_ASSERT argument
expressions. This would be an issue in this case, because that
variable is only reference in other OSMO_ASSERT expressions.

Nevertheless this patch changes this to assign the variable outside
of OSMO_ASSERT.

Fixes: Coverity CID 1244239
Sponsored-by: On-Waves ehf
sgsn: Delete PDP contexts properly

Currently the PDP contexts are hard freed (via sgsn_pdp_ctx_free)
at some places in gprs_gmm.c on the reception of a Detach Req and on
re-use of an IMSI that is already associated with an MM context. This
can lead to segfaults when there is a pending request or a data
indication at libgtp.

This patch add a new function sgsn_pdp_ctx_release that de-associates
the PTP context from the MM context, deactivates SNDCP, sets pdp->mm
to NULL and then calls sgsn_delete_pdp_ctx. sgsn_libgtp is updated to
check for pdp->mm being non-NULL before dereferencing it. The
sgsn_pdp_ctx_release function will be called for each PDP context of
an MM context before this context is going to be deleted via
sgsn_mm_ctx_free. To ensure, that the ctx->llme (which is accessed
during the deactivation of SNDCP) remains valid, the called to
gprs_llgmm_assign is moved after the call to sgsn_mm_ctx_free. The
handling of IMSE re-used is changed to mimic the processing of a
Detach Req.

Addresses:
<0002> gprs_gmm.c:654 MM(/f6b31ab0) Deleting old MM Context for same
    IMSI p_tmsi_old=0xc6f19134
<000f> gprs_sgsn.c:259 PDP freeing PDP context that still has a
    libgtp handle attached to it, this shouldn't happen!
[...]
SEGFAULT

Ticket: OW#1311
Sponsored-by: On-Waves ehf
gbproxy/test: Add expect_msg checks to test_gbproxy_keep_info (TODO)

This patch adds assertions to check the LLC/GMM message received from
the gbproxy by the test framework within the function
test_gbproxy_keep_info.

It also fixes the source address of the DETACH ACC messages.

TODO:
 - more tests

Sponsored-by: On-Waves ehf
gbproxy: Patch BSSGP P-TMSI in PAGING PS messages (TODO)

TODO:
  - commit message
  - finish test case

Sponsored-by: On-Waves ehf
sgsn: Send detach(re-attach) instead of gmm status if TLLI unknown (TODO)

The osmo-sgsn sends Status messages (or nothing in case of non
GMM/GSM) when the TLLI is unknown. This prevents the MS from
reconnecting.

This experimental patch initiates a MT detach procedure to force a
re-attach to set up a valid LLE context.

TODO:
  - test cases
  - use sgsn_force_reattach_oldmsg from within GMM, too
  - cleanup
  - note about LLC in commit message

Note that the MS can be put into REGISTERED state after initially
wanting to detach itself, since it will receive a Detach Req
(re-attach) after the SGSN or gbproxy (P-TMSI patching enabled) has
been restarted. This same behaviour has been observed with another
SGSN.

Sponsored-by: On-Waves ehf
sgsn: Added TODOs (TODO)

TODO:
  - fix and remove TODOs
  - remove this commit

Sponsored-by: On-Waves ehf