Fix CompositorResizeLock to do something.

Currently CompositorResizeLock doesn't work unless deferred since the
base class tries to use a virtual method from its constructor which
doesn't know about the subclass yet.

This fixes that and makes the following changes in the process:

I noticed that there are no longer any unit tests that depend on
ResizeLock being an interface. So I made CompositorResizeLock the
concrete type.

I noticed that CompositorResizeLock was in located in files named
compositor_resize_lock_aura.{h,cc} but is not named for aura anymore,
and is in fact used in non-aura cases for mac. So I renamed the files,
and moved the aura pieces out to DelegatedFrameHostClientAura.

In order for DelegatedFrameHostClientAura to know when to release
events however, it needs to know when the resize lock ends. So I
introduced CompositorResizeLockClient, which tells when the lock is
over.

Importantly, the above is not the same as the CompositorLock ending.
That can be done by calling CompositorResizeLock::UnlockCompositor,
which does not end the resize lock, but does release the
CompositorLock inside it. So this doesn't inform the client at
that time until the resize lock actually ends. I've tried to make
this more clear with function names and comments.

In order to unit test everything I've pulled CompositorLock out
of compositor.h and removed the friend relationships between
Compositor and CompositorLock. To do so CompositorLock now has 2
interfaces:
- CompositorLockClient which it informs about timeouts. This is
so that CompositorResizeLock knows when its internal
CompositorLock is released by timeout.
- CompositorLockDelegate which performs actual unlocking. This is
the ui::Compositor outside of tests.

Lastly, CompositorResizeLock has a timeout, and CompositorLock has
a timeout. These happen to be the same number tho
CompositorResizeLock allows you to override it. I've combined these
into a single timeout (with the help of CompositorLockClient). And
will allow GetCompositorLock to request a specific timeout. With
that, Compositor no longer needs SetLocksWillTimeOut which has some
action-at-distance properties. This maintains the property that the
first to grab a lock chooses the timeout for all other locks grabbed
during that time, however Mac code which wants no timeouts now
doesn't cause other parts of the system to also get no timeout unless
the mac lock is currently active without a timeout.

R=piman@chromium.org
BUG=704928
NOTRY=true

Review-Url: https://codereview.chromium.org/2773433003
Cr-Commit-Position: refs/heads/master@{#460577}
25 files changed