Allow custom status page templates

[colega]

What this PR does:

Upstream projects may want to render pages in different ways, applying custom branding where necessary. This allows passing a custom page template to both memberlist and ring status handlers through the configuration.

Also extracted the templates into separate .gohtml files, this enables proper syntax highlighting in the IDEs. Sorry for the noise here as it's not really important for the change I'm proposing, but I just couldn't see that long constants along with the code.

Which issue(s) this PR fixes:

First approach for #148

Checklist

• Tests updated
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[colega]

We need this to add custom branding to our enterprise metrics product, wdyt about this approach @pracucci ?

[pstibrany]

If we do this, we are effectively making statusPageData struct (and its exposed fields) part of public API, as external templates will rely on this struct not changing field names.

I'm not opposed to the idea, but we should take that into consideration and document the struct properly, to avoid breaking it.

(update: httpResponse struct in ring package as well)

[colega]

Yes, I agree on that and it's also a concern for me. I agree that we should document it, and I was wondering if we should also export it (it's not needed to render the template, but if expose it, we'll allow upstream to instantiate it for the test). However, exporting would require exporting a whole chain of fields.

I also considered writing an exported (non _test.go) test here that would be ran from the upstream (too) to check that a template contains the fields, which would make upgrades safer, however after writing it I didn't include it in the commit since I thought it's too opinionated on what should be rendered (maybe someone wants to render a template without some field?).

---

OTOH, I also considered an option of exposing something like this:

func (r *Ring) CustomHTTPHandler(customTemplate *template.Template) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, req *http.Request) {
		newRingPageHandler(r, r.cfg.HeartbeatTimeout, customTemplate).handle(w, req)
	})
}

To avoid having to pass the template through the config (that would also allow having different handlers with different templates, although we don't really have a solid use case for that (like rendering a very minimal option?).

---

In general, I think that the ring and memberlist functionality is too tied here to the handler, so I'd also consider the option of separating the handler into a different package (like ring/http) and exporting the necessary methods on the ring itself for that, allowing at the same time alternative implementations of the status handler (so we wouldn't need to pass the template here).

We could keep the ring being a http.Handler with the ring/http implementation, and allow upstream to define their own ones if needed.

(This last option would be my favorite option actually, but I'd like to hear other opinions before touching and moving stuff)

[pracucci]

I consider this PR already good :)

We could keep the ring being a http.Handler with the ring/http implementation, and allow upstream to define their own ones if needed.

Design wise, I also like the option of decoupling the ring implementation from the http.Handler() logic. If picking this option, do we need to move the HTTP implementation to a different package? Wouldn't a different file in the same package be enough? I think we'll end up always exposing the ring/memberlist UI via HTTP.

[colega]

Wouldn't a different file in the same package be enough? I think we'll end up always exposing the ring/memberlist UI via HTTP.

Yes, sure it would be enough, but I kind of dislike cluttered packages with all kind of stuff dropped together, and I think that having a dedicated sub-package with just the http-serving logic would leave the main packages (both memeberlist and ring) straight to the point: handling the business logic.

[pstibrany]

Yes, sure it would be enough, but I kind of dislike cluttered packages with all kind of stuff dropped together, and I think that having a dedicated sub-package with just the http-serving logic would leave the main packages (both memeberlist and ring) straight to the point: handling the business logic.

In my opinion self-contained "ring" or "memberlist" package with (default) handlers in them is better compared to creating another "handlers" package with dependencies to everything else.

(It would make sense to have separate ring/handler ring/http and memberlist/handler memberlist/http packages – with dependency to single package, but that seems like overkill given there is only single handler.)

[pstibrany]

I'm fine if we make methods/structs in ring and memberlist packages public, so that others may write their own handlers, as long as we document all of it properly. (I believe this is your suggestion too)

[colega]

Okay! Thank you both for the feedback. I'll open another PR for this, meanwhile, PTAL at this one just extracting templates to their own files in order to make future ones cleaner: #147