When the cursor is moved by the user, the RichInputConnection
is told about it. However, to work around a framework bug, it
also looks at how many characters are in the buffer before the
cursor, and if that's more than the value it's been passed, it
deduces that's a framework bug and there are at least as many
characters as seen before the cursor, so it puts the expected
cursor position there.

When you move the cursor, TextView calls onUpdateSelection,
and when you move it fast, you'll get rapid-fire calls to
onUpdateSelection. This is fine, the RIC is equipped to
deal with that.

However, these calls take some time to make it to the IME. In
this instance, when the first call gets through and the IME
calls TextView (synchronously) for text before the cursor, the
cursor has already moved in the app, and TextView returns more
characters than the cursor position was declared to be in this
instance, so the RIC sets that as the expected cursor position.
Sure enough, a split second later, the second call to
onUpdateSelection arrives, with the new cursor position set
where the RIC had found it too early. The RIC takes that as an
"expected" cursor move, and the input does not get reset.

Luckily, we have a way out. As far as we know, the framework bug
only manifests itself upon rotation, which means we should only
have to adjust for it in onStartInputView. Doing it in
onUpdateSelection is too zealous (and probably too distrustful of
the app to send the correct cursor positions).

So we should just take care of the rotation case (by calling
tryFixLyingCursorPosition in onStartInputView) and remove the
compensating code in resetCachesUponCursorMoves.

Bug: 12982502
Change-Id: Ic3c1408a1ec45deaea63b01d98376a79ae567d77