Refactor request: bi-directional communication betweend daemon and ui & remove dependence on UI model

[GaelicGabe]

I would like to implement an architecture refactor. Specifically something that I'm having trouble with is that there is a lot of data duplication between the UI and the daemon for example they both manage a Playlist that needs to keep in sync. Preferably there should be a source of truth for data, in the case of the Playlist this SOT should exist in the daemon (since we want to be able to play music without a UI open etc).

Removing the data duplication from the UI does not have to happen immediately, but I would like to build a system that allows for removal of UI data when the need arises.

My suggested new architecture has the data stored in the daemon and instead of having uni-directional communication from UI to daemon (with occasional polling for example in the progress bar) it has bi-directional communication where the daemon sends updates to the UI and the UI sends commands to the daemon. Doing it this way should allow the UI to be slimmed down by a lot since it can replace all synchronization logic with logic that listens to the daemon gRPC interface for updates and then simply updates the view as something changes.

[tramhao]

You are right. This is a problem I met when implement server. The playlist should be managed by the server, and the client can fetch it from server. And all the editing of this playlist should be finished by sending request to server, then fetch updated playlist again. This way it's cleaner.

Yesterday, after I merged the big PR of refactoring daemon, I met a lot of problems. Would you please send the playing track PR first, then try to avoid problems I met? I have to revert so that the code in master can work normally.