fix(wm): add read timeout to command socket

After investigating further the issue where commands would randomly stop working, we've noticed that the issue seems to be that somehow the listening thread gets stuck reading the unix socket, as in it continuously tries to read a socket on a connection that is not sending anything anymore. The result would be that komorebi would no longer be able to receive commands until it was restarted.

This fix adds a read timeout of 1s and it spawns a new thread to handle the stream reading and process of cmds. So in case this happens again, that specific processing thread will only be stuck for 1s but the rest of komorebi will never get stuck and should keep working normally.

@LGUG2Z I still don't know the cause of this issue, but this fix should work no matter what is causing it.

I did manage to somewhat be able to reproduce this by simply having a new app that connects to the komorebi socket and does a read_to_string on the socket. What I was expecting was that this new testing app would get stuck trying to read an empty socket forever, but komorebi would still be working fine, however what I saw was that after the new app calls read_to_string the komorebi listener triggers the .incoming() as if some client had written something to the socket which didn't happen, so komorebi will try to read the socket as well and it also gets stuck!

This is I believe what is actually happening, now I don't know how exactly it is happening. Somehow some client is making a read call without anything being written. So I'm not sure how it happens, it must be some combination of timing, CPU usage and the actual USER using some keybinding to call a command at the same time...

By the way, with this fix if I use that testing app mentioned above to try to recreate the issue, komorebi never stops working (doesn't even hang for 1s, I keep spamming focus change commands and it never fails, stops or hang), only the testing app hangs for 1s and then finishes.

No matter what it is, this fix should work. But the only way to know for sure is to put it out there and see if users stop reporting the issue.

I'm sorry it took this long to put this fix up, since it is such a simple fix we could probably have merged this before and would know by now if there were users still reporting the issue or not, but I was really trying to figure out the root cause of the issue, what is causing it...

LGUG2Z / komorebi

fix(wm): add read timeout to command socket #1112