Maybe we can change rotation_request_id_ to a queue of rotation requests and then rotate for each requests in the queue before we start a new rotation animation.

What does CTS expected in this case: A -> B -> C -> A?
Does it only care about there is at least one rotation and the final direction is A?

Technically speaking all of them should happen although A->B->A is most likely good enough for CTS.

Even from Android API point of view, the orientation request isn't guaranteed,
so I'll just change so that new request will not cancel current request.

Thanks oshima@.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/79f156eeee8e61d30c8939a96fd8d05f5ac233f7

commit 79f156eeee8e61d30c8939a96fd8d05f5ac233f7
Author: Mitsuru Oshima <oshima@chromium.org>
Date: Thu Oct 04 21:37:44 2018

Apply the pending rotation immediately when new request is made while waiting for copy.

Requesting new rotation while coyping layer used to cancel
the existing rotation and moved to new one, which was causing
an issue in Android CTS. Instead, apply the requested orientation
immediately and move to next rotation.

This still skips the pending request if yet another request is made
while doing rotation animation. I don't think this will cause issues
on Andrid so I'm leaving it as is.

Bug:  891737 
Test: covered by unittests.

Change-Id: Ic558ecccf594664d1f7b91b830aca33f5ba89d9f
Reviewed-on: https://chromium-review.googlesource.com/c/1257143
Commit-Queue: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Tao Wu <wutao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596867}
[modify] https://crrev.com/79f156eeee8e61d30c8939a96fd8d05f5ac233f7/ash/rotator/screen_rotation_animator.cc
[modify] https://crrev.com/79f156eeee8e61d30c8939a96fd8d05f5ac233f7/ash/rotator/screen_rotation_animator.h
[modify] https://crrev.com/79f156eeee8e61d30c8939a96fd8d05f5ac233f7/ash/rotator/screen_rotation_animator_unittest.cc