MPRIS: Use delay timer to fix update spam

[ferdnyc]

OK, since we have a little time to wait until KDE Connect 1.33.2 makes it to user devices (see #1931), I figure let's get a couple of other fixes in to the next release. This is a fix for the MPRIS spam issue I reported a few weeks ago, details in #1919. I've tested it, and it seems to work well enough — I sometimes still see two MPRIS packets being sent in a row, but that's still a lot better than 10-15 like before.

My only real issue with it is that the 250ms timer I'm using to deduplicate metadata updates is just so... arbitrary. That alone makes it feel like an imperfect solution, but it's better than nothing so I don't want to let the perfect be the enemy of the good. Thus, this PR. Commit message description follows...

Because the MPRIS plugin listens for metadata changes from players, and because it will create a new update packet for each change and immediately send it to the paired device, something like a media change (advancing in a playlist, for example) can cause 10-15 property changes in a span of milliseconds, potentially firing a barrage of 10-15 kdeconnect.mpris packets at the device. Worse, because each of these packets contains a full metadata dump, they're 10-15 nearly identical packets, except for a single changed value.

To mitigate this spam, start a 250ms timer running whenever the _onPlayerChanged() listener fires, and only create the update packet when the timer expires. Ignore any other _onPlayerChanged signals while the timer is running.

Responses to user actions or any kdeconnect.mpris.request packets received will be sent immediately, aborting any running timer, so responsiveness is not impacted.

Fixes #1919

[ferdnyc]

Hmm, probably should've run the tests on it, before creating the PR. (I think I know what it's mad about, I commented out the initial _sendPlayers() the plugin does on connect — the remote device sends a request anyway, just like we do, so I figure why not wait for that?

But I'll probably have to adjust the test accordingly.

[ferdnyc]

I commented out the initial _sendPlayers() the plugin does on connect — the remote device sends a request anyway, just like we do, so I figure why not wait for that?

Yeah, turns out... not so much. It doesn't automatically send anything. So I put back the sendPlayers().

[ferdnyc]

There was an actual bug in my code, now fixed.