GitLab

This CL makes Ozone/Wayland able to exchange clipboard data with
other applications on the system. It accomplishes the functionality
by making use of wl interfaces like wl_data_source, wl_data_offer,
wl_data_device and wl_data_device_manager.

In order to bridge the communication between Ozone backends (eg wayland)
and the rest of Chromium, CL also introduces a 'delegate' class
class named ClipboardDelegate. In practice, clients of ClipboardDelegate
(eg Mus' ClipboardImpl) delegate clipboard operations to the active
Ozone backend.

FakeServer is also extended to support the various compositor side
functionalities needed so that tests in wayland_data_device_unittest.cc run.
For instance, MockDataDeviceManager, MockDataDevice, MockDataOffer,
MockDataSource classes are added, implementing the respective Wayland
compositor hooks to communicate with Wayland clients (eg Ozone/Wayland).

Last, the CL focuses on the Ozone/Wayland side of the implementation,
leaving plumbing with the rest of Chromium for follow up CLs (eg [1]).
However in order to test the functionality, wayland_data_device_unittest.cc
is introduced and mimics how a client (eg Mus) would use of the functionality.

[1] https://crrev.com/c/981372/

API footprint:

As mentioned, CL adds a new Ozone public API class: ClipboardDelegate. The
API is designed to support "promise scheme" clipboard implementations,
like to Wayland's and MacOS' NSPasteboard.

Flow:

1) Offer clipboard data (writing)
  When offering content to the system wide Clipboard (eg Chromium/Wayland
  user performs a copy or cut operation), WaylandConnection creates a
  WaylandDataSource instance, which installs listeners, including
  ::OnSend for actually exchange the data.
  WaylandDataSource then calls wl_data_source_offer to
  communicate the compositor the mimetypes available for clipboard
  operations, and then wl_data_device_set_selection to flag itself
  as the current active "clipboard owner".

  By the time data is requested from this client (eg another application on
  the system "paste" to an editor), the WaylandDataSource::OnSend callback
  is called with a mime type and a valid file descriptor passed in as
  parameters. Ozone/Wayland then writes it clipboard data into it.
  At this point, the application requesting the data is responsible for
  reading the content from the other end of pipe, and proceed with the
  editing operation on its side, once data is exchanged.

  This is exercised by WaylandDataDeviceManagerTest::WriteToClipboard
  end-to-end, ie client_1 writes data -> compositor -> client_2 reads data.

2) Requesting clibpard data (reading)
  When requesting data from the system wide Clipboard (eg Chromium/Wayland
  user performs a paste operation), WaylandConnection calls wl_data_offer_receive.
  with a valid "WriteIn" file descriptor for the current "clipboard owner"
  write data into. Once written, the data is read by Ozone/Wayland, from
  the other end of the same pipe.

  This is exercised by WaylandDataDeviceManagerTest::ReadFromClibpard
  end-to-end, ie client_2 request data -> compositor -> client_1 writes data.

BUG=578890

Change-Id: Ibfb8c26fe817e7639f32ac4bdc2f106d4b8bb513
Reviewed-on: https://chromium-review.googlesource.com/976461
Commit-Queue: Antonio Gomes <tonikitoo@igalia.com>
Reviewed-by: Robert Kroeger <rjkroege@chromium.org>
Reviewed-by: Maksim Sisov <msisov@igalia.com>
Cr-Commit-Position: refs/heads/master@{#553326}