Refactor server listen to take 'http(s)' scheme in URL

[JAORMX]

This refactor consists of two things:

• Accept 'http(s)' as a scheme

• Move the code so it's easier to add new protocols to --addr

Signed-off-by: Juan Antonio Osorio Robles jaosorior@redhat.com

[srenatus]

Looks good to me -- the thing I'm not sure about is that this way, it's either http[s] OR unix socket, but never both. If that's the intended way, 👍

[tsandall]

This looks good. The only issue I noticed is that the server errors if you supply a URL scheme for --insecure-addr:

torin:~$ opa run --tls-cert-file server.crt --tls-private-key-file server.key --addr :8181 --insecure-addr http://:9191 -s
INFO[2018-05-30T08:05:46-07:00] First line of log stream.                     addr=":8181" insecure_addr="http://:9191"
FATA[2018-05-30T08:05:46-07:00] Listener failed.                              err="listen tcp: address http://:9191: too many colons in address"

(Specifying a host in the --insecure-addr URL does not change anything.)

[JAORMX]

@tsandall right, this only applies for addr and not insecure-addr. I'm thinking in a further iteration we could deprecate insecure-addr? I think this should be all handled by addr (since it takes http and https).

[tsandall]

Deprecating --insecure-addr sounds good to me. We can leave --insecure-addr without support for URL schemes then.

I'll create a separate issue to deprecate --insecure-addr.

I've tried to summarize the new behaviour below. Let me know if this makes sense.

scheme	cert provided	listener
none	no	http
none	yes	https
http	no	http
http	yes	http
https	no	error
https	yes	https
unix	n/a	unix
other	n/a	error

This means that if you want the current https + insecure-addr behaviour you would run OPA as follows (e.g., HTTPS on 0.0.0.0:8181 and HTTP on localhost:8282):

--tls-cert-file xxx --tls-private-key-file yyy --addr :8181 --addr http://localhost:8282

Or alternatively, with URL scheme:

--tls-cert-file xxx --tls-private-key-file yyy --addr https://0.0.0.0:8181 --addr http://localhost:8282