Isolate react-app package

[alexweav]

This PR changes the package dependency hierarchy such that ui no longer depends on ui/react-app:

What was once this:

└── cmd/alertmanager/
    └── ui/
        ├── app
        └── react-app

Now becomes:

└── cmd/alertmanager/
    ├── ui/
    │   └── app
    └── react-app

i.e. the react-app endpoints are now registered separately.

This has a few benefits:

• Isolates the problem described in github.com/prometheus/alertmanager/ui package cannot be vendored #3588. reactApp has custom build tooling, downstream projects of alertmanager can choose to independently omit this if they don't wish to run that toolchain to compile.
• Due to Go's package tree-shaking, downstream projects can selectively choose which UI they want to include (or both, or neither). This makes the alertmanager dependency lighter.
• Downstream projects like Mimir or Thanos which don't want to serve the react app quite yet can choose to register the routes independently.

[alexweav]

All code in this file is purely extracted from the old ui/web.go. No substantive changes.

[gotjosh]

LGTM - this seems sensible.

[gotjosh]

For the sake of simplcity, let's call this package reactUI and name the file accordingly.

[gotjosh]

nvm, as you explained offline there's benefits to this approach - downstream consumers don't have to adopt the react-ui until it's ready. I'm good with that.

[gotjosh]

There's one more thing I think we should do here - let's make sure we version control the react-generated, and we also need a CI step that aborts if there's a difference between what we have and what is generated.

Otherwise, we don't have visibility when changes are made.

[alexweav]

This test has flaked out more than once: issue filed. #3593

Another was CircleCI failing to talk to NPM to download a dependency. This one seemed like a one-off.

[alexweav]

Drive-by fix; this test flaked a couple times. #3593

The go Settle and following assert race each other. Other tests, including further up in this same test, use a WaitReady - it seems to be missing here.

[alexweav]

-n means to avoid including file naming information.

This also happens to exclude file timestamp info, which keeps the built artifacts reproducible. Otherwise, you get diff in the compressed files every time they're rebuilt.

[alexweav]

This step will fail if the artifacts are not updated. The resulting behavior is the same as the legacy UI.

Tested as part of this PR, the test is visible in this PR's commit history.

[gotjosh]

Beautiful! Thanks very much for your contribution.

[gotjosh]

My only worry is that browsers might use these headers to know whether they should cache the bundle, but a quick Google search yielded no results.

I'll let @Nexucis and @juliusv advise on whether this is used but I'll merge for now because overall it's a nest positive for upstream consumers.

[juliusv]

I don't mind the UI package not dragging along more dependencies than needed, but checking in the entire build output for the React app seems a bit unusual to me - it's almost like checking in a compiled binary, and now you'll have commit it again for every little change in the source. In Prometheus we circumvent this problem in a different way: the embed.go.tmpl file contains a Go build tag that only builds this file when the builtinassets Go build flag is set. This flag is set when building with promu (which we use for releases), but when someone just uses the package as a Go dependency and the flag is not set, it just pulls in an empty UI via https://github.com/prometheus/prometheus/blob/main/web/ui/ui.go (which is only built when that build tag is not set). I'd prefer if we could keep Prometheus and Alertmanager in sync in that respect.