TELECOM-11880: Working fix to revert to old behaviour

[davidtrihy-genesys]

So this is in addition to the rest client fixes, it is not a complete fix as of now but it will work with what we have currently given we only use the rest client to hit one endpoint, testing this locally with a very simple script which I can flood OPTIONs requests on a single process TCP worker and this is my observations

Current 3.4 build with no upstream patches or other changes, using the mockserver to respond, mockserver listens on port 1080 which is defined as the socks port using this command ss -t -p -m -O | grep "127.0.0.1:socks users:((\"opensips\"" | wc -l to count open sockets you'll see that with a max transfers of 200 it only opens 128 using this build it will open 200 using my basic script to do 2000 simultaneous OPTIONs requests, also casually observe timeouts on 3.4 whereas no timeouts occur here.

If you run the rest client as is in 3.6 or what is in upstream 3.4 you'll see max two sockets open and the pacing of the responses are observable to the naked eye where this basic script will take a much much longer time to finish so the current rest patches are a no go at the moment for our use case, we are relying on undefined behaviour which this will expose again but in a much more performant manner.

Next steps is that this patch is in a branch for 3.6 and it is going to soak in TCA today, then I will soak this change for v1 in TCA tomorrow and as a result of both of those behaving well I will open a ticket with OpenSIPs to let them know my findings and a potential solution to expose this behaviour in a modparam, thinking something like max_concurrent_connections or something in that ballpark and also a soak on double load day

[sekharp-genesys]

looks good thru the chat session of this changes in aws Kiro :)