Introduce a web socket server for faster communications and ability to re-authenticate.

[yyjhao]

This introduces a web socket server so to allow sending player events more efficiently. It also supports a "reauth" event to allow the player to reauthenticate again (if username/password is provided in the command line interface).

The purpose of this is to make it easier to build smart player interfaces around librespot. In particular, "reauth" is useful in dealing with the occasional connection dropping issue making the player not appearing in the sportily web API player list unless the user actively connect to it through an official spotify app in the same network again.

To use this, add --ws-port <port_number> to the command, this will start a web socket server listening at <port_number>. Then, with any web socket client can connect to this port. Once connected, the client will receive messages when the player state is updated like so:

1. track update:

{
    "event": "track_update",
    "old_track_id": uid_of_old_track,
    "new_track_id": uid_of_new_track,
    "current_queue": ["list", "of", "uids", "in", "the", "current", "queue"],
    "current_index": index_of_current_track_in_queue
}

2. start to play

{
    "event": "track_started",
    "track_id": uid_of_current_track,
    "current_queue": ["list", "of", "uids", "in", "the", "current", "queue"],
    "current_index": index_of_current_track_in_queue
}
3. paused/stopped
```json
{
    "event": "track_stopped",
    "track_id": uid_of_current_track,
    "current_queue": ["list", "of", "uids", "in", "the", "current", "queue"],
    "current_index": index_of_current_track_in_queue
}

The client can also send the following message to the server:

1. "reauth": authenticate again with username/password provided in the command line
2. "play": start to play if it's currently paused
3. "pause": pause if it's currently playing
4. "next": jump to next song
5. "previous": jump to previous song

If--ws-port <port_number> is not provided it will not spawn any web socket server.

[HEnquist]

Do you have some simple example on how to use it? That would make it much easier to review. And perhaps a list of commands?

[kingosticks]

The big issue with this is that it's exactly the sort of thing was previously said belongs in a proper librespot-powered daemon, not this project, which at it's heart is a library for accessing Spotify. But since other similar features have already crept in, and people have packaged this up as a daemon as is, I can see why it's suggested. I don't personally think a new control socket belongs here.

[yyjhao]

@HEnquist I updated the description above.

@kingosticks I have some hunch about that but as you pointed out I saw the functionality of --onevent and thought it may be ok. Given that things like respotify is essentially using librespot directly it kinda make me want to have this directly in librespot, since the functionality is pretty isolated and optional anyway.

[sashahilton00]

For what it's worth, I agree with @kingosticks on this. We looked at adding a wss server to librespot, but decided that it wasn't appropriate, as librespot is a library and not a daemon. Perhaps the new maintainer feels differently, but up until now the plan was to have the websockets server in librespotd.

[ashthespy]

I'm in the same boat as both @kingosticks and @sashahilton00 - librespotd was meant to place for such things. That being said, if its going into librespot, then please make it an optional feature that can be enabled during compile time, as others wrapping the library may not need such features.

[sashahilton00]

If no one objects, I think we should close this. If OP wants it, I suggest pulling librespot in from crates.io and making their own project to include this. Alternatively, now that librespot is published, it might be an idea to start looking at librespotd as a place to implement the bells and whistles such as this.