registerApp is called on UI thread

Steps to reproduce:
- Flash krillin
- Launch Telegram
- Sign in

What should happen:
- The chat list should be populated almost instantly (depending on connection)

What actually happens:
- "No chats" is displayed, sometimes for as long as 5-8 seconds, and only then the data appears. Problem persists over app launches (not just initial sign in), so kill and re-launch to reproduce again.

Problem:
Ubuntu Push Client does a synchronous registration call, blocking the UI thread (on which the component is instantiated).

--- More details:

Instantiation of a PushClient component (even through a Loader) is causing a visible, 1-1.4 second delay in Telegram app launch, because setting appId from QML triggers a synchronous call to registerApp, that does a synchronous dbus call (which in turn probably does networking for that matter). I measured times of code execution of different parts of Telegram and found that it is the instantiation of PushClient that causes the visible short freeze when starting the app. I also commented the "appId: ..." line and confirmed the delay was no longer visible, which seems to support my thesis.

http://bazaar.launchpad.net/~ubuntu-push-hackers/ubuntu-push-qml/rtm/view/head:/src/Ubuntu/PushNotifications/pushclient.h#L38

Q_PROPERTY(QString appId WRITE registerApp READ getAppId NOTIFY appIdChanged);

when appId is set, this invokes registerApp, which contains the following code:

    // Register to the push client
    QDBusMessage message = QDBusMessage::createMethodCall(PUSH_SERVICE, register_path , PUSH_IFACE, "Register");
    message << appId;
    QDBusMessage token = bus.call(message);
[...]
    this->token = token.arguments()[0].toStringList()[0];

which looks like blocking code.

I'm marking this as Critical, as it affects Telegram, but feel free to consult the urgency with victorp. I'm rather confident he will support that importance.