Merge lp://qastaging/~mir-team/mir/cursor-spike-phase-2 into lp://qastaging/mir/0.1

nits:
l32, most of the client headers seem to stick to the 80-char-columns rule (although the style guide says 120-char-columns)

l35, 'nad'

needs fixings:
the protobuf message should have:
 optional string error = 127;

l10/l16 comment doesn't seem to match the function

l10, It wasn't immediately obvious to me from the context and functions that the "cursor_theme" and "cursor_name" were c-strings that correspond to something on the server side. (I thought we were sending a raw pixel buffer at first glance).

needs info:
How does the client get the strings (theme name/cursor name) that it needs to use this api?

although it makes sense to ignore the strings if enabled is false, it almost lends itself to having 2 functions added to the API, one concerning turning the cursor on and off, and the other setting the cursor to something different.

PASSED: Continuous integration, rev:1490
http://jenkins.qa.ubuntu.com/job/mir-ci/1651/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/1443
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/1441
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-trusty-amd64-ci/49
        deb: http://jenkins.qa.ubuntu.com/job/mir-trusty-amd64-ci/49/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-trusty-armhf-ci/49
        deb: http://jenkins.qa.ubuntu.com/job/mir-trusty-armhf-ci/49/artifact/work/output/*zip*/output.zip

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/mir-ci/1651/rebuild

Updated comments.

Not sure about the protobuf message containing error? As it stands the message is just the parameters and the function returns void (similar to release_surface for example). Should rpc configure_cursor need to return CursorResponse { optional string error } ?

Strangely not anything like this in the RPC api...either things return real values (and the error is interspersed) or return void (release surface, screencast, etc).

PASSED: Continuous integration, rev:1492
http://jenkins.qa.ubuntu.com/job/mir-ci/1656/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/1546
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/1544
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-trusty-amd64-ci/54
        deb: http://jenkins.qa.ubuntu.com/job/mir-trusty-amd64-ci/54/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-trusty-armhf-ci/54
        deb: http://jenkins.qa.ubuntu.com/job/mir-trusty-armhf-ci/54/artifact/work/output/*zip*/output.zip

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/mir-ci/1656/rebuild

with the protobuf error field, we can leave the message as I suppose, and add it later. (adding an error msg is easy, when we need it)

I guess I'll switch to needs info for the other points...
The comments are clearer, but I still don't know where to find the name of available themes from.
Is the cursor being enabled or disabled on a per-surface basis the requirement that we have? (or is it just to turn the cursor on or off on the whole screen?)
Would 2 api functions (enable/disable and select image), be more natural?

>> The comments are clearer, but I still don't know where to find the name of available themes from.

I think in general you use the default theme, either toolkits handle configuration of different theme, or the system default changes (I lend towards the second). I think the main use case for theme, is i.e. a game installs a custom crazy game cursor theme and wishes to refer to it by name as a more convenient form of uploading custom cursors via API.

>> Is the cursor being enabled or disabled on a per-surface basis the requirement that we have? (or is it
>> just to turn the cursor on or off on the whole screen?)

Cursor is being enabled or disabled per surface for XMir v. Unity8 under USC. Of course it could be done just turning the cursor on/off for the whole screen. If we did this though, we would have to introduce some sort of meditation functionality similar to the display configuration (i.e. screen cursor state request from active session). Given that there is still a need to configure cursor per surface (e.g. text input cursor v. pointer), it seems best to not introduce this second full screen cursor state behavior.

>> Would 2 api functions (enable/disable and select image), be more natural?

I decided no because it opens more questions (What happens if you select an image while cursor is disabled?). I think just setting the total cursor state per surface is a hard model to misinterpret.