rmfakecloud-proxy: Add status subcommand

[matteodelabre]

This PR addresses the points from @Eeems’ review of last PR: #448 (comment)

The new rmfakecloudctl status introduced by this PR reports whether rmfakecloud-proxy is enabled, currently active, and whether the upstream server has been set. If the upstream server is set, it also checks whether it is reachable and a valid rmfakecloud server. Here are some possible states that can be shown by the command:

Disabled (happens, for example, right after install):

Enabled, but upstream not set:

Enabled, but upstream is unreachable:

Enabled, but upstream does not seem to be an rmfakecloud server:

Enabled and working:

This PR also changes the disable command to not clean up the /opt/etc/rmfakecloud-proxy/config file. This fixes the issue where doing rmfakecloudctl set-upstream, followed by an interrupted rmfakecloudctl enable, would unset the upstream.

[Eeems]

Status command looks good, and it does indeed leave the configuration in place. Unfortunatly upon re-enable it shows me as no longer linked to the cloud. We might need to sort out how to properly clean up the xochitl configuration and reuse the pin.

I also noticed that when I tried to disable it got stuck waiting for xochtil to stop until after I entered my pin in Oxide's lockscreen. It might be good to have it detect that the application is in a stopped state, that or just detect that oxide is running and use rot to kill the application.

[matteodelabre]

Thanks for testing!

Unfortunatly upon re-enable it shows me as no longer linked to the cloud. We might need to sort out how to properly clean up the xochitl configuration and reuse the pin.

That's a good point. To be on the safe side, I programmed the enable, disable, and set-upstream commands to disconnect the user from the cloud (by killing Xochitl and removing the usertoken and devicetoken fields from ~/.config/remarkable/xochitl.conf) before doing anything. This is to avoid situations where Xochitl would try to login to another server using credentials from the previous server.

We could implement something to save credentials for each server you connect to somewhere, and restore them when you switch between servers. But is there such a strong use-case for switching between multiple servers regularly enough that it’s worth implementing this? Also, the way it’s currently implemented, we force a full sync after each server switch, and assume that files on the device should overwrite those on the server. But for users who would switch between multiple servers I’m not sure what strategy would be best in that regard.

I also noticed that when I tried to disable it got stuck waiting for xochtil to stop until after I entered my pin in Oxide's lockscreen. It might be good to have it detect that the application is in a stopped state, that or just detect that oxide is running and use rot to kill the application.

It should have force-killed Xochitl after 5 seconds. Could you tell me how to reproduce this so that I can investigate? Thanks!

[Eeems]

It probably did force kill after 5 seconds, it would still be nice if it could attempt to work with the launcher. See #515 (comment)

I think this is safe enough to merge for now. We can resolve the other issues later.

[Eeems]

@matteodelabre poke

[matteodelabre]

Seems good. Thanks for the review!