Send offer again when own peer is not initially connected

[danxuliu]

Updated version of #2488

Follow up:

• Handle out of order answers - This will require some deeper changes and it should not be a very common case, so let's do it in a follow up

How to test

• Modify the code of the external signaling server to simulate a lot of failures (sorry for the formatting, I did not find a way to use lists and blocks of code)
  • In hub.go
    • Add "math/rand" to the imports at the top
    • Replace mc, err = session.GetOrCreatePublisher(ctx, h.mcu, data.RoomType)
      in processMcuMessage with
      if rand.Intn(100) < 70 { err = nil } else { mc, err = session.GetOrCreatePublisher(ctx, h.mcu, data.RoomType) }
      to ignore a lot of offers instead of receiving them.
      - Before those lines, add
      if rand.Intn(100) < 90 { time.Sleep(10 * time.Second) }
      to delay 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 (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

Result with this pull request

The participants are eventually connected despite several offers having failed.

Result without this pull request

The participants are kept trying to connect with each other (unless the first and the second offer succeeded; in that case leave the call and join again until the wrong behaviour is shown).

[danxuliu]

/backport to stable22

[danxuliu]

/backport to stable21

[marcoambrosini]

[danxuliu]

Rebased on latest master. Tested and works 👍

[danxuliu]

/backport to stable22.1