Include listen_type in the coalescing key used during listen submission

[mattusifer]

I have a multi-scrobbler instance that is connected to Koito, but found that Koito was frequently failing to save listens. The 'now playing' entry would be visible while the track was active, but the actual listen would not be saved. I believe it is due to the case described in the buildCoalescingKey function comment:

the key not including the listen_type introduces the very rare possibility of a playing_now request taking precedence over a single, meaning that a listen will not be logged when it should

The comment mentions that this should be rare, but at one point when I counted I had lost up to 30% of listens. Any reason not to include the listen_type in the coalescing key?

I've been using this branch for a few days and have not had any dropped listens.

[gabehf]

The reason listen_type was not included in the listen type is because in testing, some clients would fire off multiple payloads at the same time, which would result in the payloads being processed at the same time, creating duplicate entries for artists etc. in the database. In order to merge this change, that would need to be tested to ensure that if a playing_now and single payload are sent basically simultaneously, they will not create dupes in the DB since processing a new artist(s), new album, and new track can take a few seconds.

I believe the offending client was Symfonium on Android if you want to try to duplicate what I encountered, but I can't remember for certain.