Handle out of order answers from the HPB

Follow up to #3732:

Out of order answers from the HPB are not properly handled, as the answer for a previous offer can be assigned to a new offer (offer sent, answer delayed, another offer sent due to not having received an answer, answer for previous offer received and assigned to the new offer)

• When there is a mismatch between offers and answers the media will not be relayed by Janus and its logs show Missing valid SRTP session (packet arrived too early?), skipping....
• Without HPB it can be known if an answer belongs to an offer with the sid field of peers and messages, but HPB messages do not include that field.
• Even if there is a mismatch between offer and answer the browser will accept the answer and the connection will be established (kind of); the connection will be stable, and the ICE connection state will not transition to failed, so it can not be relied on the normal reconnection mechanism. However, even if the connection is established the RTCPeerConnection stats show that no media is transmitted (bytesSent in outbound-rtp will be zero). Therefore it may be possible to handle this scenario by adding a watchdog that restarts the connection if no media at all was transmitted, for example, in the first 10 seconds after the media was enabled (it may not be possible to check it in the first 10 seconds after the connection was established because if the media was disabled no media would be transmitted).

How to test

• Modify the code of the external signaling server to delay handling the received offer and thus sending the answer long enough to cause the browser to send a new offer:
  • In hub.go
    • Add "math/rand" to the imports at the top
    • Before creating the publisher in processMcuMessage, add
      if rand.Intn(100) < 90 { time.Sleep(10 * time.Second) }
      to delay handling most of the offers longer than the timeout used in the WebUI to send new ones.
    • Replace ctx, cancel := context.WithTimeout(context.Background(), h.mcuTimeout) with
      ctx, cancel := context.WithTimeout(context.Background(), time.Duration(18) * time.Second)
      to ensure that the delayed offer will be eventually received by Janus (otherwise it would be cancelled due to the timeout); another option would have been to change the default timeout in the configuration.
• Setup the MCU
• Start a call with a user
• Join the call with another user or guest

Expected result

The participants are eventually connected and they can hear and see each other.

Result without this pull request

The participants are eventually connected, but they can not hear nor see the other participant (if they can join the call again, as the answer was not delayed).

Start in hub.go around processMcuMessage and the MCU timeout handling, then reproduce the delayed-answer scenario using the listed signaling-server changes. Verify that participants eventually connect and can hear and see each other, rather than showing zero media or Janus SRTP errors. The issue does not identify the WebUI connection-handling entry point, so implementation scope needs investigation.