Don't no-op logouts

[AndrewFerr]

Disconnect bridge users from their accounts on logout. This does not actually delete the Signal device being logged out of, though.

[AndrewFerr]

The latest batch of commits tries to delete devices on "hard" logout situations (like logout, or the bridge being unlinked remotely), and to clear only session keys & connections on "soft" logouts (like delete-session). I hope this makes logouts work the way they ought to.

Logging out from the bridge still doesn't unlink the bridge from the primary Signal device, though -- I did some testing and it seems like it's still the case that only the primary device can unlink other devices, and a non-primary device can't unlink itself.

This still has the provisioning API's logout command not as a no-op, but I've given it a delete-session equivalent. If its logout command should still be a no-op, I can move the non-no-op (op?) version to a new endpoint.

[smweber]

I don't know about the bridge being unlinked in the Signal app being a "hard-logout" situation. If a user accidentally unlinks (perhaps not knowing what they're doing) it's nice for them to be able to relink with few consequences. I've also told users to unlink in the app then relink their bridge to fix situations where the Signal apps encryption gets jammed up (happens shockingly often).

[smweber]

This still has the provisioning API's logout command not as a no-op, but I've given it a delete-session equivalent. If its logout command should still be a no-op, I can move the non-no-op (op?) version to a new endpoint.

I think this should be fine :)

[tulir]

Ah right, Signal doesn't allow real logouts, then it should be fine to have logout just delete the session. Should maybe also rename delete-session to something more accurate because it's deleting less than logout

[AndrewFerr]

I don't know about the bridge being unlinked in the Signal app being a "hard-logout" situation. If a user accidentally unlinks (perhaps not knowing what they're doing) it's nice for them to be able to relink with few consequences.

The reason I went for a "hard-logout" on remote unlinking is that changing it to do a "soft-logout" makes future login attempts kick me out right away. i.e. this happens:

• run login, which succeeds
• unlink the bridge device from Signal
• bridge says it got logged out
• run login again, which succeeds
• immediately get 401 responses in logs & bridge says it got logged out

[smweber]

The reason I went for a "hard-logout" on remote unlinking is that changing it to do a "soft-logout" makes future login attempts kick me out right away. i.e. this happens:

* run `login`, which succeeds
* unlink the bridge device from Signal
* bridge says it got logged out
* run `login` again, which succeeds
* immediately get 401 responses in logs & bridge says it got logged out

That's really strange, perhaps there's some difference in how login does provisioning vs the provisioning API? I definitely delete the bridge device in Signal then log back in all the time, it's how I was testing the new prekey stuff I was working on a few weeks ago - but I use the provisioning API S: