Fix post-processing of PR URLs in create_github_release action

[AliSoftware]

Related internal reference: p1731397370353649/1729610708.303749-slack-C028JAG44VD (h/t @MiSikora for noticing the issue)

What does it do?

We post-process URLs used in create_github_release to account for WP devs using them in square brackets in their release notes while this is not rendered as link in Markdown by GitHub. But that post-processing was too eager and also replacing valid URLs that were used outside square brackets but instead inside valid Markdown link syntax.

This PR fixes this to only post-process URLs that are within square brackets.

Details

Past Context: WP iOS/Android RELEASE-NOTES.txt syntax

In WordPress iOS and Android, they use the - Description of change [#1234] syntax for most of their changelog entries to reference PRs of that repo in the changelog. But when a changelog entry references a PR from another repo (mostly commonly gutenberg), they then use the - Description of change [https://github.com/wordpress-mobile/gutenberg-mobile/pull/nnnn] syntax instead (example)

This syntax would break the rendering in GitHub Releases because GitHub does not parse URLs that are inside […] as URLs (so it doesn't replace them with a proper link with shorter title etc):

Example of how it'd render if I edit the description of a WPiOS GitHub Release to use the URLs to Gutenberg PRs in square brackets the same way they were used in the RELEASE-NOTES.txt file back then:

For that reason, a while ago we introduced a post-processing of the release notes passed to create_github_release to replace full URLs to PRs (e.g. https://github.com/wordpress-mobile/gutenberg-mobile/pull/1234) with their shorthand (i.e. wordpress-mobile/gutenberg-mobile#1234) before using it as the description body of the GitHub Release

Fast-forward to now

Some other projects also use full URLs in their CHANGELOG / RELEASE-NOTES files used for create_github_release, except that unlike WordPress, they use those URLs with proper Markdown syntax for links, e.g. [#123](https://github.com/automattic/pocket-casts-android/pulls/123), as opposed to [https://github.com/automattic/pocket-casts-android/pulls/123].

This means that those are already valid links and should be left untouched. But post-processing them the same way we did so far for every PR or issue URL instead end up replacing those texts with [#123](Automattic/pocket-casts-android#123) in the GitHub Release body instead, which leads to incorrect links (interpreted as a relative link to the GitHub Release's own URL).

We thus need to ensure those are not post-processed like the ones from WP iOS/Android, and that only URLs that are within square brackets are post-processed.

Checklist before requesting a review

• Run bundle exec rubocop to test for code style violations and recommendations
• Add Unit Tests (aka specs/*_spec.rb) if applicable
• Run bundle exec rspec to run the whole test suite and ensure all your tests pass
• Make sure you added an entry in the CHANGELOG.md file to describe your changes under the appropriate existing ### subsection of the existing ## Trunk section.
• If applicable, add an entry in the MIGRATION.md file to describe how the changes will affect the migration from the previous major version and what the clients will need to change and consider.

[iangmaia]

👍