Add support for old format for narrow links

[mounilKshah]

What does this PR do, and why?

This PR contains commit which extends support to the old format for narrow links
which existed before server version 2.1.0

#zulip-terminal > Support old narrow links format #T1422 #T1424
#api-documentation > Narrow URL formats

External discussion & connections

• Discussed in #zulip-terminal in Support old narrow links format #T1422 #T1424
• Fully fixes Support old format for narrow links (subject in addition to topic) #1422
• Partially fixes issue #
• Builds upon previous unmerged work in PR #
• Is a follow-up to work in PR #
• Requires merge of PR #
• Merge will enable work on #

How did you test this?

• Manually - Behavioral changes
• Manually - Visual changes
• Adapting existing automated tests
• Adding automated tests for new behavior (or missing tests)
• Existing automated tests should already cover this (only a refactor of tested code)

Self-review checklist for each commit

• It is a minimal coherent idea
• It has a commit summary following the documented style (title & body)
• It has a commit summary describing the motivation and reasoning for the change
• It individually passes linting and tests
• It contains test additions for any new behavior
• It flows clearly from a previous branch commit, and/or prepares for the next commit

[neiljp]

@mounilKshah Thanks for taking this up 👍

This seems to work just fine, and the tests back this up.

I was going to comment that the test cases you added were a little confusing in places since the message and stream ids are identical, but I note we do that in the other situations too. On that basis, it may be useful to do some cleanup on this test, perhaps as prep commits if you're comfortable with that, namely refactor commits for:

• inlining ids
• adjusting the expected message id to be different to the stream id
• moving the SERVER_URL to be used in the test body instead?

Re the commit text, note that notes re Fixes and the tests normally go on their own lines. I think ZT or Zulip document the former; the latter is likely assumed by Zulip in general, but can be useful to confirm and distinguish between new behavior coverage, adjustments/refactors, test cases vs tests, etc.

For followup:

• We've discussed in the stream that we could document test styles/guidelines. If you'd like to draw together some elements into a document, that'd be useful to direct users towards. Another approach which I briefly explored was enabling pytest checks in ruff.
• We may be able to either document or also add checks for Fixes and tests lines to the gitlint rules we use somehow, which would lower the need to give feedback on this as frequently.

[neiljp]

@mounilKshah Thanks for the refactor 👍 Adjusted very slightly and added in a small followup commit for message vs stream id distinction I referred to.