sip: request - fix parallel use of dnsrr

[cspiel1]

If multiple SIP requests are sent in parallel to the same host then
multiple references to the same dnsrr object will be used in different
request objects. But linking of one le to multiple lists is not possible.
Now for each dnsrr reference an le object is created.

Another solution with deep copy of dnsrr: #1512

[cspiel1]

The Windows test run failed with:

  test_rtp_listen                 : 
rtptest: TEST_ERR: /home/runner/work/re/re/baresip-win32/re/test/rtp.c:553: (Unknown error [10013])

rtptest: TEST_ERR: /home/runner/work/re/re/baresip-win32/re/test/rtp.c:612: (Unknown error [10013])
test:   test_rtp_listen         : NOK: Unknown error [10013]

retest: TEST_ERR: /home/runner/work/re/re/baresip-win32/re/test/main.c:247: (Unknown error [10013])

This is not related to this PR.

Edit: Maybe should be made more stable. E.g. Maybe like here #1526

[cspiel1]

Converted to draft. Let's first complete this #1520.

[cspiel1]

It seems that this is the only location where elements are added to multiple lists (parallel SIP requests):

$ grep -r -E "list_.*mem_ref" src
src/sip/msg.c:		list_append(&msg->hdrl, &hdr->le, mem_ref(hdr));
src/sip/msg.c:			list_append(&msg->hdrl, &hdr->le, mem_ref(hdr));
src/sip/request.c:		list_append(lst, le, mem_ref(rr));

msg.c does at the end of the same function a mem_deref(hdr). Thus only in request.c the problem sits.

Thus blowing up the list API maybe is not worth to solve the issue mentioned first here: #1512.

I suggest this solution with alloc le. Disadvantage, we have to do the list flush, manually in the destructor.

[maximilianfridrich]

srvl must now also be flushed manually.

[cspiel1]

Will be replaced by an rr deep copy solution.