Changes

rtp2trau HR: bring TRAU-16k support into alignment with TRAU-8k

GSM 08.61 defines two TRAU frame formats for HRv1 codec, using
either 16 kbit/s or 8 kbit/s submultiplexing.  The 8k format is
the one actually implemented in legacy E1 BTS hardware, and is
also needed for global interoperability in TFO - whereas HR-16k
TRAU frame format appears to be a paper-only spec that was never
implemented in any hardware.

Despite the lack of hardware implementations, support for TRAU-16k
format for GSM-HR is already present in libosmotrau, originally
implemented along with FR and EFR.  Removing this support from
Osmocom would look bad (there is always that off-chance that
perhaps some BSS vendor did implement this format after all),
hence let us do the next best thing: bring TRAU-16k support into
alignment with the actually working TRAU-8k support for the same
codec.

Thanks to previous clean-up patches in this area, rtp2trau support
for GSM-HR TRAU-DL output was already fully consistent between 16k
and 8k formats, but TRAU-UL output code was wildly inconsistent.
TRAU-8k-UL output code is new, takes TW-TS-002 input and can be
used to implement TFO (primary intended use) or emulate an E1 BTS.
However, previous TRAU-16k-UL output code dates back to the initial
creation of TRAU<->RTP code in 2020, has never been updated until
now, and is woefully inadequate for the task of emulating an E1 BTS.
(Because TFO always uses 8k format for HRv1, software emulation of
an E1 BTS is the only remaining plausible application for GSM-HR
TRAU-16k-UL output.)

With the present patch, the behavior of osmo_rtp2trau() for
OSMO_TRAU16_FT_HR UL changes drastically: TS 101 318 input is no
longer accepted, RFC 5993 input is still accepted but is not
functionally complete, and the proper/expected input format becomes
TW-TS-002, of which RFC 5993 is a subset.  However, the detailed
behavior of osmo_rtp2trau() for HRv1 codec is now exactly the same
between 8k and 16k formats, in both DL and UL directions.

Change-Id: I1c19592967e7c6becc710990f512da5dee5043d2

TRAU encode: fix handling of OSMO_TRAU16_FT_IDLE

GSM 08.60 sections 3.4 and 3.5.5 (renumbered to 5.4 and 5.5.5 in
3GPP TS 48.060) define a special frame type called Idle Speech Frame.
It is not clear if any historical BSS vendor actually implemented
these special frames - Nokia documentation explicitly mentions how
they were deemed unnecessary and omitted from implementation - but
libosmotrau includes support for this frame type.

Looking at the referenced spec sections, we can see the designers'
intent: the idle speech frame is just like FRv1 speech frames,
but with different UL/DL frame type codes in C1..C5 and with all
Dn bits replaced with constant-1 filler.  Following this design
intent on the part of GSM spec authors, the philophically correct
behavior for osmo_trau_frame_encode() with regard to this frame type
should be to handle it exactly the same as OSMO_TRAU16_FT_FR
(support both DL and UL output, timing alignment in DL, possibility
of changing C6..C21 and T-bits), but don't look at fr->d_bits[],
fill constant 1s in their place instead.

However, the behavior of the encoding function for this frame type
prior to the present change was not like this at all: instead it
would emit a constant (once and for all) frame of 320 bits that was
always for DL no matter which direction was requested, would not
allow time alignment, and would not allow any C-bits to be controlled
by upper layers.

At the present time there is no code anywhere in Osmocom that feeds
OSMO_TRAU16_FT_IDLE to osmo_trau_frame_encode() - thus we don't have
to maintain backward bug compatibility, and we can fix this design bug.

Change-Id: Ibcc9e8628a56c6f089264c9d6b0dd27a1d5a7b60