Changes

rtp2trau: remove broken acceptance of 0-length payloads

Since the beginning of osmo_rtp2trau() in 2020, this API accepted
0-length RTP payloads for FR, HR and EFR, for both TRAU-DL and
TRAU-UL output.  However, this "support" never worked correctly:

* For FR & EFR in DL direction, previous patch 1d42fcd4ea40
  attempted to emit the idle speech frame of TS 48.060 section 5.4,
  following sections 6.5.2 and 6.5.3 of the same spec.  However,
  the actual combination of osmo_rtp2trau() followed by
  osmo_trau_frame_encode() resulted in an invalid FR/EFR TRAU-DL
  frame being emitted, rather than the intended special idle speech
  frame.  It is also very uncertain if real E1 BTS would handle
  that idle speech frame particularly well even if we did emit one
  correctly - it is a strange "feature" of the spec that never
  occurs in real operation of a TRAU, neither in free-running
  speech encoder state nor in TFO.

* For FR & EFR in UL direction, the same previous patch would turn
  0-length payload input (or TW-TS-001 No_Data input with later
  patches) into BFI with a peculiar fill pattern.  The fill pattern
  was all-1s in the case of FR or all-1s plus bad CRC in the case of
  EFR.  (The 5 CRCs of EFR TRAU frame format just happen to come out
  bad when all Dn bits are set to 1 - not intentional CRC inversion.)
  TRAU-UL output is not currently used anywhere in Osmocom; there is
  a plan to implement TFO in ThemWi software using Osmocom libraries,
  but this type of fixed bit fill is not a good choice for TFO frame
  output going to foreign GSM network operators.

* For HR speech to TRAU-DL conversion, the effect of 0-length payload
  input was emission of a TRAU-DL frame that looks valid, but has all
  112 bits of payload set to 0, with correct CRC.  All-zeros is a poor
  choice of LPC parameter fill for dummy GSM-HR codec frames; if an
  application wishes to implement dummy frame fill, it should control
  its own fill frame pattern, rather than expect osmo_rtp2trau() to
  provide good idle fill.

Solution: simply remove all bogo-support for 0-length RTP payload
input to osmo_rtp2trau() in the case of speech codecs, and return
-EINVAL just like for all other types of invalid RTP input.

Effect on OsmoMGW-E1: the only time when OsmoMGW could pass a 0-length
payload to osmo_rtp2trau() would be if the RTP stream comes from
OsmoBTS (not from another leg on OsmoMGW-E1) with vty option
'rtp continuous-streaming' enabled.  Prior to the present patch,
the resulting effect would be bogus output on Abis DL; after this
patch, the MGW behavior will be the same as with no RTP input -
the MGW will insert fixed fill frames at the application level,
going directly to I.460 mux.

Change-Id: Ia41ea2eab1ded094cadcd91dbd33de8800af11ee