Add insecure flag for http getter.

[chrisgilmerproj]

I have a need to use go-getter without checking the certificate chain on the http server. To accomplish this I've added a flag named -insecure that will allow me to do this. I've tried to add tons of warnings in the code and in the tool to make users aware what a bad idea it is to use this flag and that they are taking risks.

Prior to using this flag I would see:

2021/04/28 14:11:06 Error downloading: Get "https://username:***@hostname": x509: cannot validate certificate for hostname because it doesn't contain any IP SANs

After adding the flag I get this message:

2021/04/28 14:37:17 WARNING: Using Insecure TLS transport!
2021/04/28 14:37:17 success!

I am unsure how to add a test that shows this without also bootstrapping a server with bad TLS in the tests, but if that's needed I can do it. I've also tried to follow the paradigms in the code but if I've missed something I can fix it.

Finally, I noticed that one of the error messages kept spitting out an unredacted password in a URI. I added that as a security fix here but I'm happy to remove it and submit another PR.

[SwampDragons]

@tgross you offered to take a look at this one.

[tgross]

LGTM once that fix in client_option_insecure.go is made.

There's a legitimate concern here about whether we really want to support an insecure option, but as long as it's entirely opt-in we're not at risk that our known consumers like TF/Packer/Nomad are going to accidentally misconfigure it. So I'm 👍

[tgross]

Suggested change

	// Not all getters have progress support yet.
	// Not all getters have support for insecure mode yet.

Looks like this was a copy-paste error from client_option_progress.go. But this also points out to me that there's some precedent for having options that don't support all getters, which was one of my initial concerns here. 👍

[chrisgilmerproj]

I pushed a fix for the above, nice catch. I am not a huge fan of having an option that doesn't work everywhere but once I saw the progress bar I thought it would be ok. Also, there aren't good parallels for insecure for some of the other getters and I wasn't sure how to handle that.

[chrisgilmerproj]

There's a legitimate concern here about whether we really want to support an insecure option, but as long as it's entirely opt-in we're not at risk that our known consumers like TF/Packer/Nomad are going to accidentally misconfigure it. So I'm 👍

I stand with you on the concern about making this available. There are definitely modern use cases for servers which are improperly set up however making this available means folks can abuse poorly configured systems without addressing security concerns. Thankfully its opt-in and even if it doesn't get merged folks can still pull the code from this PR if they really need it.

Thanks for the review, I really appreciate you giving it some attention.