Right way to pass SITE_ID and REMARK_URL to templates

[akellbl4]

Now we build frontend and then on the running stage replace these constants with sed. It works only for docker image.
We don't do it for binary packages (correct me if I'm wrong). I will check how it works in it.

I think we should discuss and find out the right way to do it for any kind of build. We found out another one way to do it with serving templates on Go and insert them. This way also has another advantage: we can rid off the request to get config and pass it in the template right on sending HTML to a client.

cc @umputun @paskal

Related: #567 #806

[paskal]

HTML generation is a messy task no matter where you do it, and usually, I would vote against coupling frontend and backend in such a strong way. But, as we have such a small amount of the HTML I think it's not that bad, and I would indeed be glad to get rid of sed. I think we should go for it. @umputun?

[umputun]

I don't think such a coupling worths it as seds replacement. However processing html/js on the server side (like applying templates and setting extra headers) has many other good uses. For example, support of styles upload via server API and applying styles on the fly. Another example - setting some headers, like frame-ancestors, dynamically.

So, as much as I don't like the potential coupling, in our case it may have some valuable benefits.

[paskal]

@akellbl4 I see that now we have some hardcoded variables next to the htmlWebpackPlugin.options. Can we reuse the same mechanism for SITE_ID for consistency?

    site_id: 'remark',
    host: '<%= htmlWebpackPlugin.options.REMARK_URL %>',

[paskal]

cc @sattellite as he seems to be the person who added it in the first place.