ICE negotiation fails after each component has successful connectivity check

[nanang]

Ice negotiation scenario:

1. Receive ICE check response for component 1 with an unknown XOR-MAPPED-ADDRESS, ICE adds this unknown address as a new peer reflexive candidate.
2. Receive ICE check response for component 2 with the same XOR-MAPPED-ADDRESS as above (somehow!), ICE wrongly assumes it is for the same candidate as the one just created above due to similar XOR-MAPPED-ADDRESS address, hence the successful check flag is assigned to wrong component too.
3. As only two checks above are successful in the negotiation and ICE thinks both are for component 1 (so no successful check for component 2), the ICE negotiation status is set as failed.

After investigation, we found that ICE only matches the XOR-MAPPED-ADDRESS in looking up the local candidate, so in the scenario no 2 above, instead of adding a new (peer reflexive) candidate, it uses an existing one which actually belongs to a different component.

Thanks Roland Wallner for the report.

[nanang]

In 5184:

Fix #1891: Also match base address in find local candidate after receiving ICE check response.