Add support for including a Strict-Transport-Security header (for use only when a proxy or load balancer is handling TLS/SSL)

[taniwallach]

Add support for including a Strict-Transport-Security header.

This header is meant to force browsers to only contact site via TLS/SSL ("https"). Using this header is a commonly recommended security practice, but is dangerous should the site have any need to work over plain (port 80) HTTP.

The value for the header is provided in render.conf as a string value called HSTS_HEADER, and when that value is not provided (or is false for Perl purposes) no Strict-Transport-Security header will be set.

No default value is being provided in render.conf.dist so the header will not be enabled by accident.

The header should only be used on a server which is available via a proxy or load balancer which has a valid SSL certificate and handles the TLS/SSL level (and which will continue to do so for the long-term).

Note: It could be that some proxy setups could add the header at the proxy, but the AWS Elastic Application Load Balancer does not have the option to add this header, but can provide SSL termination, so the header needs to be added on the "back end" (in our case the Standalone renderer).

[taniwallach]

To test you would want to be using the renderer behind something doing the SSL work as a proxy.
In such a setting, add something like

  HSTS_HEADER => 'max-age=604800',

into render.conf.

It has been provisionally tested for a renderer running as a target to which the AWS Elastic Application Load Balancer is sending requests for processing, where the ELB is handling the TLS work. Now that this header is being provided, I hope to soon be able to open the address to incoming requests from additional sources. Until now the security team has insisted on it only be available from a very restricted white list of IP addresses. Once the "server" is public, the result of the code in this PR would be something which can be checked on that site.