At the moment, the D-Bus properties mixin imposes these restrictions on an object:

* Get() must be synchronous
* Get() must always return something (perhaps a dummy value like 0 or "")
* Get() cannot fail
* Set() must be synchronous, or pretend to be

(but Set() *may* fail.)

Mission Control already has a mixture of async set methods that are not implemented with TpDBusPropertiesMixin (Bug #32416), and async set methods that pretend to succeed synchronously, but actually do async things.

If we want to use a write-only property for "my nickname" (Bug #14540) or "my avatar" (Bug #55920), or make MC more honest about sync/async, then we need to have an async Set method.

Two options:

* Have vfuncs for set_async, set_finish. The default implementation of set_async would be "call the synchronous setter". I'm tempted to do them in terms of GVariant, too.

* WONTFIX this, and have MC and CMs override Set() to do this instead:

  if (interface == COMPLICATED_1)
    ...
  else if (interface == COMPLICATED_2)
    ...
  else
    {
      if (tp_dbus_properties_mixin_set (self, ..., &error))
        dbus-glib: return successfully
      else
        dbus-glib: return with error
    }

My concern about that second option is that the properties mixin gives us a nice data-driven multiplexer for all the interfaces, which becomes less useful.

For Bug #32416, MC also needs a version of tp_dbus_properties_mixin_set() that will allow setting properties that aren't actually flagged as read/write, for things like Parameters... unless we rework MC to pass a dict of initial properties as a construct-time property of accounts (and duplicate most of their setter logic, unfortunately) instead of constructing a blank account and poking properties into it like it does now.

I have about half a branch for async set in TpDBusPropertiesMixin.