Changes

mgcp_test.c: fix various missing '\r' and '\n'

The only valid line endings are '\n' and '\r\n'.
We usually use '\r\n' like we were in MSDOS.

MGCP, RFC3435 3.1:

   Headers and session descriptions are encoded as a set of text lines,
   separated by a carriage return and line feed character (or,
   optionally, a single line-feed character).

SDP, RFC8866 5:

   The sequence CRLF (0x0d0a) is used to end a line,
   although parsers SHOULD be tolerant and also accept lines terminated
   with a single newline character.

There should probably be tests for '\n' line endings, but mixing them in
the same MGCP message is ridiculous.

Change-Id: I6d530535a3a5f1d1a0716ab9e4a8079ba1de242e

mgcp_test: test a=ptime:20, not 40

In our GSM world, the packet time is 20 ms, hence 20 is the typical
value that we should test. Maybe we can do one test with 40 at most, but
we'll most probably never see anything else than 20 in practice.

Change-Id: Ia2292198bf6e3b72912afd69607654ca77fd549d

mgcp_test: add CRCX for IUFP in sendrecv

Note, there are also ttcn3 tests sending the same to osmo-mgw being
submitted along with these patches, and the ttcn3 tests currently fail:
osmo-mgw rejects the connection mode "sendrecv" in the first CRCX.

Change-Id: Icdb1085b8e44ac4cff6c457163349b81e81bf765

do not FAIL on CRCX in sendrecv mode

Currently, a CRCX in sendrecv mode results in:

  DLMGCP ERROR endpoint:rtpbridge/2@mgw CI:7F4C8EDD CRCX: selected connection mode type requires an opposite end! (mgcp_protocol.c:1090)

But it is not actually practical, nor logical to require another conn
for the 'sendrecv' ConnectionMode.

Impractical: If I want to create two conns on an endpoint that both are
in 'sendrecv' mode, I have to send two CRCX, one for each conn. At the
time of the first CRCX, there cannot be any other conn, so I am
currently forced to send a different ConnectionMode in the CRCX,
followed by another MDCX later, just to change the first conn to
sendrecv.

Illogical: In a situation where two conns are currently in sendrecv
mode, if I now DLCX one of them, I can legally reach a state with a
single conn in sendrecv mode, just as currently forbidden for CRCX.

In general, MGCP is not forcing any particular number of connections.

Simply start forwarding RTP as soon as there is a remote conn, and not
require another explicit MDCX.

Related: SYS#6974 SYS#6907
Related: osmo-ttcn3-hacks I00fd854f058f7f53e2f579e8481ca2b9253f08e3
Change-Id: Ic089485543c5c97a35c7ae24fe0f622bf57d1976