WIP: Use similarity in AutoDJ functionality

[gwicke]

• Use the compilation library to pull in similarity stats for the current
  song, and use this as factors in an overall similarity ranking.
• Convert lastQueueDate ranking into one of several factors contributing to
  the rank, with the intention of making the proportion of each criteria
  configurable, possibly using sliders.
• Make the randomness of the selection (how likely it follows the ranking)
  configurable.

[andrewrk]

Kudos for suggesting using your compilation library by providing an example implementation.

These are some big changes to the way that Groove Basin works which bring up some philosophical questions, such as:

• Should Groove Basin depend on third party APIs for core functionality like choosing the next song?
• Should we try to come up with a more generic solution that would work for untagged music or unpopular music that might not be in Spotify?

On the more technical side, I'm also looking to confirm:

• Does the compilation library handle all exceptions properly by propagating errors?
• Do its dependencies?

[gwicke]

@andrewrk, the way this is currently structured as a combination of several weighted inputs would make it quite easy to disable external API usage when the weight of those similarity metrics is set to zero. I could imagine a set of sliders under 'preferences' for this. I am not up to date with the state of offline music similarity libraries, but could imagine those becoming another optional input. They could also work well on un-tagged / rare music.

If the general direction towards score plugins makes sense to you, I could take a stab at refactoring the patch around one.

Does the compilation library handle all exceptions properly by propagating errors?

I'm open to suggestions. The current code hides errors from individual backends, but I could just as well tweak the interface to expose them. We don't want to fail the entire request if one of several APIs has a temporary outage, but it might make sense to provide information about such errors, and perhaps fail the response overall if none of the backends responded within the timeout.

Do its dependencies?

Yes, the web requests are all done with https://github.com/wikimedia/preq, a thin promise wrapper around request. We are using this library at high volume in production at wikimedia, so I am confident in its stability. One of the features it adds is systematic handling of errors, including raising HTTPErrors for responses with status >= 400.