MM-57839: Rewrite static assets only if needed

[agarciamontoro]

Summary

Refactor UpdateAssetsSubpathInDir so that the actual rewriting of files happen in two different functions: one for root.html, another for manifest.json and *.css files.

I would have wanted to simply do an if pathToReplace == newPath { return nil } when those two are defined, but the logic for root.html is not that simple*, and that may miss some edge cases, so I opted out for simply moving the actual rewriting to individual functions, which check for their corresponding conditions to perform the update:

1. for root.html, check that the edited file is indeed different than the original one
2. for manifest.json and *.css files, rewrite them only if pathToReplace != newPath, which in this case is clear that that's the only modification we do.

The logic is exactly the same as before except for skipping the rewrite when those conditions are not met.

*I don't really understand this block:

// Determine if a previous subpath had already been rewritten into the assets.
reWebpackPublicPathScript := regexp.MustCompile("window.publicPath='([^']+/)static/'")
alreadyRewritten := false
if matches := reWebpackPublicPathScript.FindStringSubmatch(string(oldRootHTML)); matches != nil {
	oldSubpath = matches[1]
	alreadyRewritten = true
}

When can that be rewritten if not here?

Ticket Link

https://mattermost.atlassian.net/browse/MM-57839

Screenshots

--

Release Note

NONE

Fix #26769

[agarciamontoro]

@hmhealey, adding you here in case you're familiar with this client static assets rewriting.

[agnivade]

Swapping me for Jesse, who should have more context on this area.

[lieut-data]

Nice!

[lieut-data]

Would it make sense to just log nothing in this case? (Unix philosophy and all?)

[agarciamontoro]

Oh, I didn't know that was part of the Unix philosophy 👀 But given this is a debug-level log, I'm in favour of keeping it. I don't think there's such thing as a lot of debug logging! If you have a stronger opinion, I can change it.

[lieut-data]

I'm only 0/5, but if we DEBUG logged everything that /didn't/ happen, I would wager that would be a /lot/ of debug logging ;P. My hope whenever scrubbing logs is to look for positive evidence of something, and in that context, fewer logs that speak to something that actually happened are strictly more helpful. But this is a one-off, so I'm really only -1/5 :D

[unified-ci-app]

E2E test triggered successfully for PR #27076. The corresponding commit's status check will be available shortly.

[github-actions]

E2E test run is starting for commit 7ce20bcee6599533c597432973860e83c44bc385.
You can check its progress by either:

• Looking at the corresponding commit status, which will be available in a few moments: E2E Tests/test.
• Looking at the E2E test's Workflow Run, with Run ID 9225496091.
• Looking at the E2E test's Cycle on the Automation Dashboard.

[agarciamontoro]

@DHaussermann, this PR modifies the code that updates the static assets served by MM when changing the subpath where the application is served. Could you run a smoke test to ensure that everything is working as expected? If something is broken, it should be quite obvious, as in nothing works. We should ideally test that changing the subpath also works, but I don't know how easy that is (if it's even possible) in a cloud test server.