Reason for revert:
I think this causes WebRtcBrowserTest.CallAndModifyStream to fail on Android. See https://code.google.com/p/webrtc/issues/detail?id=4857 for more info.
Original issue's description:
> Fixing scenario where track is rejected and later un-rejected.
>
> Added `RestartLocalTracks` and `RestartRemoteTracks` methods to
> `MediaStreamHandlerContainer` which will redo the track handlers'
> initial setup; most importantly, this will re-connect the
> renderer/capturer/etc. to a channel which was destroyed and then
> re-created.
>
> Also added `AcceptRemoteTracks` method to MediaStreamSignaling, which
> does the inverse of `RejectRemoteTracks`. Effectively this will notify
> sinks that the track is live again, after previously being set to
> `kEnded` when it was rejected.
>
> BUG=webrtc:2136
>
> Committed: https://crrev.com/be37888b6d5d269dbd5385569dba15c0d70594f2
> Cr-Commit-Position: refs/heads/master@{#9600}
TBR=pthatcher@webrtc.org,juberti@webrtc.org,deadbeef@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:2136
Review URL: https://codereview.webrtc.org/1247443005
Cr-Commit-Position: refs/heads/master@{#9622}
Added `RestartLocalTracks` and `RestartRemoteTracks` methods to
`MediaStreamHandlerContainer` which will redo the track handlers'
initial setup; most importantly, this will re-connect the
renderer/capturer/etc. to a channel which was destroyed and then
re-created.
Also added `AcceptRemoteTracks` method to MediaStreamSignaling, which
does the inverse of `RejectRemoteTracks`. Effectively this will notify
sinks that the track is live again, after previously being set to
`kEnded` when it was rejected.
BUG=webrtc:2136
Review URL: https://codereview.webrtc.org/1231613002
Cr-Commit-Position: refs/heads/master@{#9600}
