Mute muted users (Chris's revision, 1 of 2)

[chrisbobbe]

Stacked atop #1530.

Thanks @sm-sayedi for your work on muted-users, and for making sure I had your latest revision of #1429 before you left for vacation! 🙂

With the launch coming up, and since you're on vacation, I've gone ahead with taking #1429 forward with my own changes, as we discussed last week, rather than doing another round of review.

This PR is part of that work; more to come. In particular, this PR doesn't include the part of #1429 that excludes muted users and messages. It only affects how they appear in the UI.

Notable differences from #1429:

• Centralized the "Muted user" placeholder condition in store.userDisplayName and store.senderDisplayName, as suggested in the issue and in Distinguish muted users in UI #1429 (review). (With some commits beforehand, to use those methods everywhere it makes sense to use them.)
• I got the InheritedWidget strategy to work (Distinguish muted users in UI #1429 (comment) ); I think this is simpler and clearer.
• I've extended ZulipWebUiKitButton for the "Reveal message" button, rather than making a new ad hoc button. ZulipWebUiKitButton handles subtle things like a scale animation on press, and making sure its touch target is 44px tall even if the painted button is shorter (24px in this case).
• If a muted message is starred, this revision still shows the star, following web.
• Some adjustments to the tests.
• Some splitting of commits (like the rename of some members of DesignVariables)

Related: #296

[chrisbobbe]

"Reveal message" button and "Muted user" placeholder in the message list, then "Hide muted message again" option in the action sheet:

Light	Dark

[alya]

The slashed eye icon seems to be missing half its iris. It doesn't have that effect on web.

[alya]

The screenshots look fine to me otherwise.

[gnprice]

Thanks for the careful implementation! I've read the first N-1 commits:
e4db89d users: Have userDisplayEmail handle unknown users
46dbe1e lightbox: Use senderDisplayName for sender's name
cdb2dd2 compose: Fix error on quote-and-replying message from unknown sender
23413ab users [nfc]: Use userDisplayName at last non-self-user sites in widgets/
1107261 muted-users: Say "Muted user" to replace a user's name, where applicable
fe9f5be theme [nfc]: Rename some variables that aren't named variables in Figma
96bfe26 muted-users: Use placeholder for avatars of muted users, where applicable
794544c msglist [nfc]: Provide MessageListPageState via an inherited widget
cdcb1bc msglist [nfc]: Remove a no-op MainAxisAlignment.spaceBetween in _SenderRow
168c787 button [nfc]: Have ZulipWebUiKitButton support a smaller, ad hoc size
731d714 button [nfc]: Have ZulipWebUiKitButton support an icon
d5553a4 button [nfc]: Have ZulipWebUiKitButton support ad hoc minimal-neutral type

and partway through the last one:
c90fa9d msglist: Hide content of muted messages, with a "Reveal message" button

[gnprice]

I think this comment is still relevant for explaining a choice we made about how this logic works.

(The name mention needs updating, though — already did, to say userMention.)

[gnprice]

muted-users: Say "Muted user" to replace a user's name, where applicable

(Done by adding an is-muted condition in store.userDisplayName and
store.senderDisplayName, with an opt-out param.)

Cool, I like this structure.

The inventory of where we say "Muted user" and where we don't is also helpful:

If Chris is muted, we'll now show "Muted user" where before we would
show "Chris Bobbe", in the following places:

- Message-list page:
  - DM-narrow app bar.
  - DM recipient headers.
  - The sender row on messages. This and message content will get
    more treatment in a separate commit.
  - Emoji-reaction chips on messages.
  - Typing indicators ("Muted user is typing…"), but we'll be
    excluding muted users, coming up in a separate commit.
  - Voter names in poll messages.
- DM items in the Inbox page. (Messages from muted users are
  automatically marked as read, but they can end up in the inbox if
  you un-mark them as read.)
- @-mention autocomplete, but we'll be excluding muted users, coming
  up in a separate commit.
- Items in the Direct messages ("recent DMs") page. We'll be
  excluding DMs where everyone is muted, coming up in a separate
  commit.
- User items in custom profile fields.

We *don't* do this replacement in the following places, i.e., we'll
still show "Chris Bobbe" if Chris is muted:

- Sender name in the header of the lightbox page. (This follows
  web.)
- The "hint text" for the compose box in a DM narrow: it will still
  say "Message @Chris Bobbe", not "Message @Muted user". (This
  follows web.)
- The user's name at the top of the Profile page.
- We won't generate malformed @-mention syntax like
  @_**Muted user|13313**.

[gnprice]

nit: Let's rename to just of, either in this commit or right after it. The "ancestor of" name was meant to give a bit of pause when one considers calling it, because it suggests the idea of walking up the tree through ancestors, whereas .of is the usual convention for finding an InheritedWidget.

[gnprice]

This isn't specific to _MessageListPageState.setState, is it? I believe this means the dependent elements will get rebuilt any time the MessageListPage gets rebuilt. Which could e.g. be because one of its own dependencies was updated.

[gnprice]

Maybe the cleanest thing would be to have the InheritedWidget be an InheritedNotifier, specifically for the set of muted messages. That set could be an object like this:

class RevealedMutedMessagesState extends ChangeNotifier {
  final Set<int> _revealedMessages = {};

  bool isMutedMessageRevealed(int messageId) =>
    _revealedMessages.contains(messageId);

  void _add(int messageId) {
    _revealedMessages.add(messageId);
    notifyListeners();
  }

  // … _remove …
}

Then the bit on _MessageListPageState would look something like this:

  final _revealedMutedMessages = RevealedMutedMessagesState();

  @override
  void revealMutedMessage(int messageId) {
    _revealedMutedMessages._add(messageId);
  }

And it wouldn't have an isMutedMessageRevealed method directly; instead, there'd be a static on MessageListPage that looks like static RevealedMutedMessagesState revealedMutedMessagesOf(BuildContext context). A caller that needs isMutedMessageRevealed starts by calling that static, which creates a dependency; then it calls isMutedMessageRevealed on that; and the dependency ensures that the caller gets notified if the data changes.