Link go.mod dependencies to pkg.go.dev in the source viewer

What does this MR do and why?

go.mod is highlighted by the backend today. go_mod is listed in LEGACY_FILE_TYPES, so the file is served through the legacy viewer, where the server-side DependencyLinker runs. Module paths are linked on master; nothing is broken.

This MR moves the file type over to the frontend source viewer without losing those links. It adds a Highlight.js dependency linker for go_mod, registers it in link_dependencies.js next to the existing go_sum one, and removes go_mod from LEGACY_FILE_TYPES — the same sequence the go.sum linker followed in 7a86007a.

Every module path links to pkg.go.dev:

• A require entry with a version links to that exact version, https://pkg.go.dev/<module>@<version>, so the reader lands on the documentation for what the project actually builds against. Pseudo-versions such as v0.0.0-20220127200216-cd36cc0744dd and // indirect markers are handled.
• The module directive, the tool directive, and the left-hand side of replace and exclude link to the module without a version.
• Both the block form (require ( ... )) and the single-line form (require github.com/foo/bar v1.0.0) are covered, and the keyword may be followed by any whitespace rather than a single space. When a tab separates the module path from the version, the tab is preserved rather than collapsed to a space.
• retract is not in the keyword list, because it takes version ranges rather than a module path.

Only the module path becomes the link text; the version stays as plain text after it, so the line reads exactly as before. go 1.17 and toolchain go1.21.0 have no module path and are left untouched, as is anything after => in a replace directive.

go.mod is highlighted as plaintext, so each line arrives as a single <span class="">...</span> with => already escaped as =>; the regex is written against that exact shape.

References

• Resolves #367655
• Sibling changes moving linkers to the new viewer: !255262 (merged) (Podfile), !255264 (merged) (podspec), !255265 (merged) (Cartfile) and !255267 (merged) (requirements.txt).
• Follows the shape of the existing go_sum_linker.js in the same highlight_js/plugins/utils directory and reuses createLink from dependency_linker_util.js, so links carry the same target and rel attributes as every other linker.
• Each of these MRs removes its own entry from LEGACY_FILE_TYPES, so whichever merges after another may need a trivial one-line rebase on that array.

Differences

Before: go.mod was rendered by the legacy backend viewer, with links produced by Gitlab::DependencyLinker::GoModLinker.

After: go.mod is rendered by the frontend source viewer, with the same links produced client side. github.com/BurntSushi/toml inside a require block links to https://pkg.go.dev/github.com/BurntSushi/toml@v0.3.1, opening in a new tab, with v0.3.1 left as plain text after it. gitlab.com/gitlab-org/gitlab-workhorse on the module line and golang.org/x/tools/cmd/stringer on a tool line link to pkg.go.dev without a version. go and toolchain lines are unchanged.

How to set up and validate locally

In a project, add a file named go.mod with the following content:

module gitlab.com/gitlab-org/gitlab-workhorse

go 1.17

toolchain go1.21.0

require (
github.com/BurntSushi/toml v0.3.1
gitlab.com/gitlab-org/labkit v1.3.0 // indirect
golang.org/x/net v0.0.0-20220127200216-cd36cc0744dd
)

require github.com/stretchr/testify v1.8.0

tool golang.org/x/tools/cmd/stringer

replace github.com/foo/bar => ../bar

retract v1.0.1

Open the file in the repository view. Each module path in the require entries should link to pkg.go.dev at its listed version, including the one separated from the keyword by a tab. The module, tool and replace paths should link to pkg.go.dev without a version. The go, toolchain, retract and ../bar parts should not be links.

Specs:

yarn jest spec/frontend/highlight_js/plugins/utils/go_mod_linker_spec.js spec/frontend/highlight_js/plugins/link_dependencies_spec.js

go_mod_linker_spec.js covers block and single-line require entries with plain and pseudo-versions, an // indirect marker, the tool directive in both forms, a tab between keyword and module path, a tab preserved between the module path and version, the module and replace directives without a version, and that go and toolchain lines are untouched. link_dependencies_spec.js asserts go_mod is routed to the new linker.