I thought you were on the mark when you identified the need for discourse to be aware of http_x_forwarded_proto, but why do we need a redirection rule here?
If SSL termination is done by an external proxy which forwards requests to discourse over HTTP, then discourse still may need to know that it can accept submissions as secure, and that it can and should produce https URLs in pages.
If Discourse doesn’t have this capability, then I imagine the best alternative is to have the proxy use HTTPS to talk to discourse, though it’s wasteful of CPU, and may add to certificate management. I’ve yet to look into what happens with conflicting LetsEncrypt configurations between the proxy and the back end, but suspect it might be a source of trouble.