Implement future sync points in gpu service

Implement future sync points in gpu service

This adds a |retire| parameter to InsertSyncPoint and adds a
RetireSyncPoint call so future sync points (which do not implicitly
retire on insertion) can work.

R=piman@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/e24b02460c0d2e39d1427688805811d2ffa2ad3b

[jamesr, 2014-11-20 22:17:56]

abarth@ - I lied to you slightly about how future sync points work.  They don't
allow you to completely skip doing an IPC round-trip to allocate the sync point
ID, but they do let you do make that round-trip before you actually want to
retire the sync point which lets you move it out of the critical path.  There's
still a risk that you insert a sync point, tell someone else you retired it, and
then not actually retire the sync point but you can't just make up a sync point
completely client-side.

piman@ - PTAL when you get a chance. I don't think we are using future sync
points anywhere in mojo but we'll quite possibly want to.

[piman, 2014-11-20 22:52:59]

LGTM, but keep in mind that future sync points can allow untrusted code to
create deadlocks (insert and never retire), and possibly security issues (retire
a sync point that doesn't belong to you).
For that reason in Chrome we only allowed the browser to create and retire
those. You may want to do something along those lines in mojo.
I think it's possible to avoid the second problem (by properly scoping sync
points, or making them unguessable), but I don't think we can fully avoid the
first one (at least not easily).

[jamesr, 2014-11-21 19:04:04]

Good point.  Filed https://code.google.com/p/chromium/issues/detail?id=435641 to
make sure we don't forget it.  I think the implementation is pretty independent
of the policy surrounding it, so I'll go ahead and land this now.

[jamesr, 2014-11-21 19:04:14]

Committed patchset #1 (id:1) manually as
e24b02460c0d2e39d1427688805811d2ffa2ad3b (presubmit successful).