Revert of Move "max IPv6 networks" logic to BasicPortAllocator, and fix sorting.

Revert of Move "max IPv6 networks" logic to BasicPortAllocator, and fix sorting. (patchset #2 id:20001 of https://codereview.webrtc.org/2983213002/ )

Reason for revert:
Breaks IpcNetworkManagerTest.TestMergeNetworkList, because it has built-in assumptions about network ordering that it shouldn't have. Will reland after fixing that test.

Original issue's description:
> Move "max IPv6 networks" logic to BasicPortAllocator, and fix sorting.
> 
> This CL moves the responsibility for restricting the number of IPv6
> interfaces used for ICE to BasicPortAllocator. This is the right place
> to do it in the first place; it's where all the rest of the filtering
> occurs. And NetworkManager shouldn't need to know about ICE limitations;
> only the ICE classes should.
> 
> Part of the reason I'm doing this is that I want to add a
> "max_ipv6_networks" API to RTCConfiguration, so that applications can
> override the default easily (see linked bug). But that means that
> PeerConnection would need to be able to call "set_max_ipv6_networks" on
> the underlying object that does the filtering, and that method isn't
> available on the "NetworkManager" base class. So rather than adding
> another method to a place it doesn't belong, I'm moving it to the place
> it does belong.
> 
> In the process, I noticed that "CompareNetworks" is inconsistent with
> "SortNetworks"; the former orders interfaces alphabetically, and the
> latter reverse-alphabetically. I believe this was unintentional, and
> results in undesirable behavior (like "eth1" being preferred over
> "eth0"), so I'm fixing it and adding a test.
> 
> BUG=webrtc:7703
> 
> Review-Url: https://codereview.webrtc.org/2983213002
> Cr-Commit-Position: refs/heads/master@{#19112}
> Committed: https://chromium.googlesource.com/external/webrtc/+/ad9561404c0cc007574eaedade581928aa3d24ef

TBR=zhihuang@webrtc.org,pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7703
Review-Url: https://codereview.webrtc.org/2984853002
Cr-Commit-Position: refs/heads/master@{#19114}
Committed: https://chromium.googlesource.com/external/webrtc/+/817c8af52ac12227fc4603f908443dcde33fb186

[Taylor Brandstetter, 2017-07-21 19:59:32]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2017-07-21 19:59:33]

Created Revert of Move "max IPv6 networks" logic to BasicPortAllocator, and fix
sorting.

[commit-bot: I haz the power, 2017-07-21 19:59:40]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2017-07-21 19:59:46]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1500667172904990, "parent_rev":
"d14d9f741433f49f9c321b6d3565c4e5a61deb5e", "commit_rev":
"817c8af52ac12227fc4603f908443dcde33fb186"}

[commit-bot: I haz the power, 2017-07-21 19:59:51]

Description was changed from

==========
Revert of Move "max IPv6 networks" logic to BasicPortAllocator, and fix sorting.
(patchset #2 id:20001 of https://codereview.webrtc.org/2983213002/ )

Reason for revert:
Breaks IpcNetworkManagerTest.TestMergeNetworkList, because it has built-in
assumptions about network ordering that it shouldn't have. Will reland after
fixing that test.

Original issue's description:
> Move "max IPv6 networks" logic to BasicPortAllocator, and fix sorting.
> 
> This CL moves the responsibility for restricting the number of IPv6
> interfaces used for ICE to BasicPortAllocator. This is the right place
> to do it in the first place; it's where all the rest of the filtering
> occurs. And NetworkManager shouldn't need to know about ICE limitations;
> only the ICE classes should.
> 
> Part of the reason I'm doing this is that I want to add a
> "max_ipv6_networks" API to RTCConfiguration, so that applications can
> override the default easily (see linked bug). But that means that
> PeerConnection would need to be able to call "set_max_ipv6_networks" on
> the underlying object that does the filtering, and that method isn't
> available on the "NetworkManager" base class. So rather than adding
> another method to a place it doesn't belong, I'm moving it to the place
> it does belong.
> 
> In the process, I noticed that "CompareNetworks" is inconsistent with
> "SortNetworks"; the former orders interfaces alphabetically, and the
> latter reverse-alphabetically. I believe this was unintentional, and
> results in undesirable behavior (like "eth1" being preferred over
> "eth0"), so I'm fixing it and adding a test.
> 
> BUG=webrtc:7703
> 
> Review-Url: https://codereview.webrtc.org/2983213002
> Cr-Commit-Position: refs/heads/master@{#19112}
> Committed:
https://chromium.googlesource.com/external/webrtc/+/ad9561404c0cc007574eaedad...

TBR=zhihuang@webrtc.org,pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7703
==========

to

==========
Revert of Move "max IPv6 networks" logic to BasicPortAllocator, and fix sorting.
(patchset #2 id:20001 of https://codereview.webrtc.org/2983213002/ )

Reason for revert:
Breaks IpcNetworkManagerTest.TestMergeNetworkList, because it has built-in
assumptions about network ordering that it shouldn't have. Will reland after
fixing that test.

Original issue's description:
> Move "max IPv6 networks" logic to BasicPortAllocator, and fix sorting.
> 
> This CL moves the responsibility for restricting the number of IPv6
> interfaces used for ICE to BasicPortAllocator. This is the right place
> to do it in the first place; it's where all the rest of the filtering
> occurs. And NetworkManager shouldn't need to know about ICE limitations;
> only the ICE classes should.
> 
> Part of the reason I'm doing this is that I want to add a
> "max_ipv6_networks" API to RTCConfiguration, so that applications can
> override the default easily (see linked bug). But that means that
> PeerConnection would need to be able to call "set_max_ipv6_networks" on
> the underlying object that does the filtering, and that method isn't
> available on the "NetworkManager" base class. So rather than adding
> another method to a place it doesn't belong, I'm moving it to the place
> it does belong.
> 
> In the process, I noticed that "CompareNetworks" is inconsistent with
> "SortNetworks"; the former orders interfaces alphabetically, and the
> latter reverse-alphabetically. I believe this was unintentional, and
> results in undesirable behavior (like "eth1" being preferred over
> "eth0"), so I'm fixing it and adding a test.
> 
> BUG=webrtc:7703
> 
> Review-Url: https://codereview.webrtc.org/2983213002
> Cr-Commit-Position: refs/heads/master@{#19112}
> Committed:
https://chromium.googlesource.com/external/webrtc/+/ad9561404c0cc007574eaedad...

TBR=zhihuang@webrtc.org,pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7703

Review-Url: https://codereview.webrtc.org/2984853002
Cr-Commit-Position: refs/heads/master@{#19114}
Committed:
https://chromium.googlesource.com/external/webrtc/+/817c8af52ac12227fc4603f90...
==========

[commit-bot: I haz the power, 2017-07-21 19:59:52]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/external/webrtc/+/817c8af52ac12227fc4603f90...