Don't overwrite the active account when composing from a notification

[nikclayton]

Fix a bug where the active account can be overwritten.

1. Have two accounts logged in to Tusky, A and B
2. Open Tusky as account A
3. Send a DM to account B (doesn't have to be a DM, just anything that creates a notification for account B)
4. Restart Tusky so the Android notification for the DM is displayed immediately. You are still acting as account A.
5. Drag down the Android notification, you should see two options, "Quick reply" and "Compose"
6. Tap "Compose"
7. ComposeActivity will start. You are now acting as account B. Compose and send a reply
8. You'll be returned to the "Home" tab.

The UI will show you are still account A (i.e., it's account A's avatar at the top of the screen, if you have the "Show username in toolbars" option turned on it will be account A's username in the toolbar).

But you are now seeing the home timeline for account B.

Fix this.

ComposeViewModel

• Do not rely on the active account in sendStatus(), receive the account ID as a parameter

ComposeActivity

• Use either the account ID from the intent, or the current active account. Do not change the active account
• Pass the account ID to use in the sendStatus() call

[nikclayton]

Possibly implicated in #2663 ...?

[connyduck]

Very nice find!

I believe the correct fix for this is to not open ComposeActivity directly, but MainActivity and then ComposeActivity. This way MainActivity can also switch accounts, and it is consistent with other places where we open ComposeActivity from the outside (e.g. when sharing to Tusky or using a shortcut).

[nikclayton]

Sure, but can we fix the bug while preserving existing behaviour first, and then move on to changing the behaviour?

[connyduck]

I think the behavior is wrong and it is the bug, but sure

[nikclayton]

I agree. I've filed #3695 to track fixing this so it's consistent with other parts of the code.