Ensure correct StarToggleButton signal handler state

[rmol]

Description

StarToggleButton.on_authentication_changed would just keep connecting signal handlers without ever disconnecting those previously installed.

When not authenticated, we'd set a signal handler to show the "You must sign in" message when pressed. That handler was never disconnected once authentication was successful, so if the timing were right at startup, it would get installed permanently.

Similarly, we could end up with multiple on_toggle handlers, sending multiple UpdateStarJobs for a single click on the StarToggleButton.

This change disconnects all handlers for the previous authentication state when authentication state changes.

Also, the Controller.is_authenticated setter emitted the authentication_state signal before updating self.__is_authenticated. To prevent that ever being a problem for signal handlers that check the property and not the signal value, the order of those calls has been swapped.

Fixes #919.

Test Plan

• Run the client with LOGLEVEL=debug, preferably in an environment where you were able to reproduce starring requiring login after already logged in #919 (I could only trigger the problem in sd-app talking to my staging environment; it never happened for me in the dev environment).
• Log in to the client.
• Try to star a source. It should work, without an error message saying you need to log in.
• Log out.
• Try to star a source. It should not work, and you should see an error message saying you need to log in.
• Log back in and star a source.
• Check the client log. Only one UpdateStarJob should have been sent for your last action.

Checklist

If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable:

• I have tested these changes in the appropriate Qubes environment
• I do not have an appropriate Qubes OS workstation set up (the reviewer will need to test these changes)
• These changes should not need testing in Qubes

If these changes add or remove files other than client code, packaging logic (e.g., the AppArmor profile) may need to be updated. Please check as applicable:

• I have submitted a separate PR to the packaging repo
• No update to the packaging logic (e.g., AppArmor profile) is required for these changes
• I don't know and would appreciate guidance

[sssoleileraaa]

won't this disconnect many times? why can't we just disconnect once? it seems like an exception has to be raised in order for this to exit the loop?

[rmol]

It will disconnect all the connections of self.on_toggle_offline that have been made. There should only ever be one now. And yes, the exception raised when no such connection exists is what exits the loop.

[sssoleileraaa]

did adding a self.toggled.disconnect() and self.pressed.disconnect() before this line not work?

[rmol]

It did.

[sssoleileraaa]

This works as described. I'm just surprised that we have to diconnect in a while-true loop and hoping for more of an explanation for why we can't disconnect the toggled and pressed signals just once before we reassign slots?

[rmol]

The disconnect loop is just belt-and-braces caution, to ensure we never accumulate more than one connection for a handler.