Add lock for OPKG.

[stylesuxx]

OPKG commands are now put on a FIFO queue. Before processing an item, we check if the opkg lock file is present, if so we wait a bit re-checking the file. Should the lock not resolve after a given amount of time, we stop processing the queue, rejecting all items.

Processing an opkg command is also guarded by a timeout, should a given command not finish processing withing 60 seconds, we consider the operation failed and reject all other queued OPKG commands. This rejection does not affect the OPKG command running on the device, which might finish even after rejection in the client.

All of this should improve potential race conditions that might arise due to checking for updated when the application starts up and the user doing other package related operations in the mean time, like for example loading the package list.

TODOs:

• [x] Check loading of package list
• [x] Check rejection of package list
• [x] Check loading of package details
• [x] Check rejection of package details
• [x] Check loading of package installation (detail page)
• [x] Check rejection of package installation (detail page)
• [x] Check loading of package removal (detail page)
• [x] Check rejection of package removal (detail page)
• [x] Check loading of package installation (listing page)
• [x] Check rejection of package installation (listing page)
• [x] Check loading of package removal (listing page)
• [x] Check rejection of package removal (listing page)
• [x] Check loading of package updates
• [x] Check rejection of package updates
• [x] Check rejection of upgradable packages
• [x] Remove timeout

[j005u]

Make sure to test the 60 second timeout thoroughly against wtfos-system install (wtfos install), we make a copy of /system, patch both slots and get up to other hijinks. I'm not sure 60 seconds is definitely enough.

[stylesuxx]

Installation process is excluded from the queue.

But we can also increase this timeout or remove it completely - I was hesitant to put in in at all since people tend to get inpatient after a minute or so anyway and would probably reload in the mean time. For now I still need it for testing though.

[j005u]

Installation process is excluded from the queue.

Sanity check: not uninstall right? Or pretty much any other operation for that matter? I just had trouble uninstalling today due to locking issues, ended up resorting to butter.

[j005u]

Also for a major update with eg. ffmpeg getting pulled, let's say lots of packages are involved, on a dog slow internet connection - 1 minute may not entirely be enough. Also I couldn't promise wtfos-system updates won't ever want to re-do some parts of the partition mirroring etc.

I would err on the side of 5 minutes to avoid issues with edge cases? I.e. somebody still using IDK 200kbps DSL?

[stylesuxx]

Correct. Uninstall and everything else goes through the queue, just during installation we custom set the PATH that's why I don't put it through the queue.

OK, I'll remove the timeout completely - seems to end up in more of a hassle than doing good.

[stylesuxx]

Alright - this ended up to be quite the overhaul of the package management. @j005u could you give this PR a try please and see if you notice anything not working?

To simulate the lock, you can just touch the file manually /opt/tmp/opkg.lock.

When manually triggering package related actions there should now be error messages passed through (and shown in the UI) from the actual call - this should make debugging a bit more transparent.