pool: http allow client to send credentials when TLS is used

[paulmillar]

Motivation:

If dCacheView makes a GET request against the WebDAV for which it
supplies credentials and the door redirects dCacheView to a pool then
dCacheView will use the same credentials when making the GET request to
the pool. This bug is recorded as dCache/dcache-view#254.

Currently, the pool responds to the CORS preflight request indicating
that the client must not send credentials. When faced with this
conflict, the web-browser fails the GET request.

It looks like it's currently impossible to prevent the web-browser from
resending the WebDAV-credentials to the pool (see whatwg/fetch#944).

Therefore, to support dCacheView, the pool must allow client
credentials, which (in turn) is only safe for TLS-protected transfers.

Modification:

Update pool's CORS configuration to allow the client to send a
credential for https transfers.

The pool continues to ban sending credentials for http (i.e.,
unencrypted) transfers.

Result:

dCacheView now works for redirected transfers for non-anonymous data
access, provided the WebDAV door is using TLS encryption and is
configured with 'webdav.redirect.allow-https' set to 'true'. This, in
turn, requires the pool has TLS enabled and presents an X.509
certificate from a CA that the browser trust.

Target: master
Requires-notes: yes
Requires-book: no
Request: 7.1
Request: 7.0
Request: 6.2
Request: 6.1
Request: 6.0
Request: 5.2
Patch: https://rb.dcache.org/r/13018/
Acked-by: Tigran Mkrtchyan
Acked-by: Lea Morschel