Fix issues around soft deactivation and push notifications

[timabbott]

Today I discovered that soft-deactivated users don't get mobile push notifications for messages on private streams that they have configured to send push notifications. This is pretty poor, since the whole purpose of this feature is to help these users learn about things happening in that stream. (I think email notifications may still work).

Here's the problem:

• handle_push_notification calls access_message, and that logic assumes that a user who is a recipient of a message has an associated UserMessage row
• We create those UserMessage rows lazily for soft-deactivated users, so they might not exist (yet) until the user comes back.

The outcome is access_message throwing an exception in handle_push_notification. There are 2 ways one could imagine fixing this:
(1) Ensuring do_send_messages creates a UserMessage row when a user has configured a stream to send mobile push notifications or emails, so that our notifications code can always assume a UserMessage row is present. This should completely cover the notifications use case where this originally came up, since the whole soft-deactivation model is that it's always OK for UserMessage rows to have been created before soft-reactivation.
(2) Changing access_message to do something fancy for soft-deactivated users, effectively calling a function wrapping filter_by_subscription_history to create just that one UserMessage row on-demand if appropriate. This would ensure that all of our API endpoints grant the user access to the message. We might need to also do something similar in validate_attachment_request; I'm not sure.

I think we definitely want to do (1), because that helps simplify the understanding required for our notifications code. It is possible we also want to do (2); but let's hold off on thinking about that until we've implemented (1); I think for performance reasons, (1) is worth doing regardless of whether we also do (2).

For (1), I think it would suffice to change this block in get_recipient_info to exclude stream_push_user_ids and stream_email_user_ids from the list.

    long_term_idle_user_ids = get_ids_for(                                                                                                  
        lambda r: r['long_term_idle']                                                                                                       
    )                                                                                                                                       

See https://zulip.readthedocs.io/en/latest/subsystems/sending-messages.html#soft-deactivation for background.

@showell @adnrs96 FYI.

[shubham-padia]

@zulipbot claim

[zulipbot]

Hello @shubham-padia, you claimed this issue to work on it, but this issue and any referenced pull requests haven't been updated for 10 days. Are you still working on this issue?

If so, please update this issue by leaving a comment on this issue to let me know that you're still working on it. Otherwise, I'll automatically remove you from this issue in 4 days.

If you've decided to work on something else, simply comment @zulipbot abandon so that someone else can claim it and continue from where you left off.

Thank you for your valuable contributions to Zulip!

[timabbott]

I merged #10491, which covers the urgent/proximal issue here. I'm leaving the remaining issue open for us to think about whether we also want to modify access_message to handle similar issues automatically in the future; there is a very real performance tradeoff to be mindful of there.