content: Change UserMention to render user mentions dynamically

[Ruhdee]

Fixes #1258

Before	After
User mention shows old name "Old Name"	User mention shows current name "New Name" from store

Changes:

Model:

Added userId, isSilent and updated parser.

Widget:

Modified widget to fetch username from store and handle isSilent flag.

Tests:

Updated parser tests and added new widget tests.

Doubts:

1. Running flutter analyze gives error on code from main branch as mentioned in Analyzer error: invalid @override on factory constructors in submessage.dart #2082

UPDATE: Removing the error causing annotations fixes the CI testing issue. However, since this code change is not related to issue #1258, please advise on how I should proceed.

2. Old widget tests for UserMention don't pass store. So I've added defensive check for store in UserMention widget even though store will probably never be null in production. Should I keep the code as it is or should I change all old tests for UserMention?

[gnprice]

Thanks! This looks quite promising.

Here's some high-level comments. Once you address these, the PR will be ready for a more detailed maintainer review.

First, to your questions:

Running flutter analyze gives error on code from main branch

Yeah, including a fix for that is fine as long as it's a separate commit, which you've done.

Old widget tests for UserMention don't pass store. So I've added defensive check for store in UserMention widget even though store will probably never be null in production.

Yeah, we don't want to add that sort of logic. It makes the code more complicated to read and think through, and it makes the behavior in tests diverge from the behavior in the real app.

Instead, any existing tests that start needing a store widget should add one. Lots of our other existing tests provide a store widget, because lots of our other widget code requires one, so it should be possible to do this with very little added code. This change can happen as its own separate prep commit, before the change that makes it necessary.

---

One of your later commits changes some existing tests so that they pass. Those changes should instead happen in the same commits that make them necessary. In general, if you check out any individual commit and run tools/check there, it should pass.

Another later commit adds tests for an earlier commit. Instead, those tests should be added in the same commit as the code they test.

[Ruhdee]

Changes made:

1. Rebased onto main. This fixed the @override annotations error.

Instead, any existing tests that start needing a store widget should add one. Lots of our other existing tests provide a store widget, because lots of our other widget code requires one, so it should be possible to do this with very little added code. This change can happen as its own separate prep commit

2. Added preparatory tests commit according to above
3. Squashed tests commits to where model or widget changes were made

Please review changes.

Small question: Is it ok to tag maintainers, like so: @gnprice, when feedback is addressed to speed up the review process? The contributing guide doesn't specifically advise for or against it in the "How to help move the review process forward" section.

[gnprice]

Cool, thanks for the revision. This looks ready for a more detailed review.

Is it ok to tag maintainers, like so: @gnprice, when feedback is addressed to speed up the review process?

It's not really harmful to tag maintainers on a PR thread, but doesn't have much effect. I already watch this repo and so get notifications for every update to every PR.

More generally on GitHub, anyone who's already participating in the thread can be expected to be subscribed and so getting notifications for every update, with or without an @-mention. That means that GitHub @-mentions are mainly useful for pulling someone into a thread for the first time.

The main thing to do when you've addressed feedback is just to post a comment clearly saying you've done so. That way when a maintainer looks at it, it's clear that it's ready for the next review and not still waiting for a revision from you.