In the course of validating #125, we discovered that using the stdlib's
[`httptest.ResponseRecorder`][0] mechanism to drive the vast majority of
our unit tests led to some slight brokenness due to subtle differences
in the way those "simulated" requests are handled vs "real" requests to
a live HTTP server, as [explained in this comment][1].

That prompted me to do a big ass refactor of the entire test suite,
swapping httptest.ResponseRecorder for interacting with a live server
instance via [`httptest.Server`][2].

This should make the test suite more accurate and reliable in the long
run by ensuring that the vast majority of tests are making actual HTTP
requests and reading responses from the wire.

Note that updating these tests also uncovered a few minor bugs in
existing handler code, fixed in a separate commit for visibility.

P.S. I'm awfully sorry to anyone who tries to merge or rebase local test
changes after this refactor lands, that is goign to be a nightmare. If
you run into issues resolving conflicts, feel free to ping me and I can
try to help!

[0]: https://pkg.go.dev/net/http/httptest#ResponseRecorder
[1]: https://github.com/mccutchen/go-httpbin/pull/125#issuecomment-1596176645
[2]: https://pkg.go.dev/net/http/httptest#Server

Fixes #128

`go-httpbin` was incorrectly returning `http` as the scheme for its URL
if you ran it with TLS specified via `HTTPS_CERT_FILE` and
`HTTPS_KEY_FILE`. Update it to return https as the scheme in this case
by checking if `r.TLS` is not nil

Before:

```
$ mkcert test
$ docker run -e HTTPS_CERT_FILE='/tmp/test.pem' -e HTTPS_KEY_FILE='/tmp/test-key.pem' -p 8080:8080 -v $(pwd):/tmp mccutchen/go-httpbin
$ curl -sk https://localhost:8080/get | jq -r .url
http://localhost:8080/get
```

After (TLS):

```
$ docker run -e HTTPS_CERT_FILE='/tmp/test.pem' -e HTTPS_KEY_FILE='/tmp/test-key.pem' -p 8080:8080 -v $(pwd):/tmp llimllib/go-httpbin
$ curl -sk https://localhost:8080/get | jq -r .url
https://localhost:8080/get
```

After (no TLS):

```
$ docker run -p 8080:8080 llimllib/go-httpbin
$ curl -sk http://localhost:8080/get | jq -r .url
http://localhost:8080/get
```

I got the idea for how to check the scheme from [this SO
post](https://stackoverflow.com/a/61446922/42559)

When a request to `/anything` has an empty body, the `data` field of the
output should be the empty string. Currently, `go-httpbin is returning
`data:application/octet-stream;base64,`.

- Should the output actually be null? That would match `files`, `form`,
and `json`, but also would require deeper changes since `Data` is stored
as a string not a pointer, and I didn't want to mess with things any
more than I had to. An empty string works fine for my purposes
- how can I test this PR? I tried but I got confused by the TestAnything
method
- all the current tests pass under this change

This PR closes #124. Before:

```
$ curl -s 'http://0.0.0.0:8080/anything?one=two'
{
  "args": {
    "one": [
      "two"
    ]
  },
  "headers": {
    "Accept": [
      "*/*"
    ],
    "Host": [
      "0.0.0.0:8080"
    ],
    "User-Agent": [
      "curl/7.88.1"
    ]
  },
  "method": "GET",
  "origin": "127.0.0.1:60402",
  "url": "http://0.0.0.0:8080/anything?one=two",
  "data": "data:application/octet-stream;base64,",
  "files": null,
  "form": null,
  "json": null
}
```

After:
```
$ curl -s 'http://0.0.0.0:8080/anything?one=two'
{
  "args": {
    "one": [
      "two"
    ]
  },
  "headers": {
    "Accept": [
      "*/*"
    ],
    "Host": [
      "0.0.0.0:8080"
    ],
    "User-Agent": [
      "curl/7.88.1"
    ]
  },
  "method": "GET",
  "origin": "127.0.0.1:60595",
  "url": "http://0.0.0.0:8080/anything?one=two",
  "data": "",
  "files": null,
  "form": null,
  "json": null
}
```

```console
# before: httpbingo lacks the "method" field but httpbin.org has it
$ curl -s https://httpbingo.org/anything | jq .method                                                                                                        9:31PM
null
$ curl -s https://httpbin.org/anything | jq .method
"GET"

# after: httpbingo has the method field!
$ curl -s http://0.0.0.0:8080/anything | jq .method
"GET"
```

This was mentioned in #6, but then not listed in #91

- I took the highly technical testing approach of adding a test for
`Method` anywhere in `handlers_test.go` that mentioned `Args`; do you
desire more tests? fewer tests?
- Anywhere else I should add this field that I didn't already?

For what it's worth, I discovered this when working on upgrading the
testing for our [httpsnippet
library](https://github.com/readmeio/httpsnippet); I wanted to use
`go-httpbin` but our tests expect the method field to be present in the
responses

Also, switch to URL-safe base64 instead of standard base64, for
compatibility with original httpbin.

Fixes #118.

This brings go-httpbin's behavior more in line with original httpbin.

Fixes #90.

Fixes #112.

BREAKING CHANGE: Requests for zero bytes now actually return zero bytes.
Requests for negative numbers of bytes are now rejected.

This can help debug misconfigurations, where it's useful to know whether a 404 response is due to a configuration issue in some upstream proxy (load balancer, gateway, etc) or due to an actual bad request to go-httpbin.

A few small improvements to the test suite:
- Ensure `/stream` and `/stream-bytes` endpoints actually use
`Transfer-Encoding: chunked`, instead of inferring/hoping based on
Content-Length header
- Explicitly test that `/drip` actually does sleep between writing
bytes, rather than inferring that it does based on entire response
duration

Make the error message when a forbidden destination is given to
`/redirect-to`, to help users better understand what allowed usage looks
like. Motivated by #103.

Before: 

```
$ curl http://localhost:8080/redirect-to?url=https://google.com
Forbidden redirect URL. Be careful with this link.
```

After:

```
$ curl http://localhost:8080/redirect-to?url=https://google.com
Forbidden redirect URL. Please be careful with this link.

Allowed redirect destinations:
- example.com
- example.org
```

This is a very small improvement to developer ergonomics.

The `/redirect-to` endpoint currently acts as an open redirect, which is
bad for any go-httpbin instance exposed to the public internet.

This allows configuring an allowlist of domains to which traffic can be
redirected.

Instead of serializing JSON to a temporary slice of bytes before writing
to the response, instead write directly to the response.

Also, pretty-print JSON responses for better readability (and to match
httpbin).

Note: With this change, we rely much more on the underlying net/http
server's implicit handling of the Content-Length header. One notable
side effect of this is that responses to HEAD requests no longer include
a Content-Length.

- Handle bodies for GET requests to the /anything endpoint
- Do not encode HTML tags in serialized JSON

We were not explicitly testing the behavior of some HTTP verb endpoints
like /put and /patch, because they currently share an underlying handler
with /post which is thoroughly tested.

The addition of the /anything endpoint in #83 made me realize a bit more
explicit test coverage would be good, so here we're landing a bit of a
refactoring of the test suite to generate tests for all of those
endpoints.

Along the way, we also improve compatibility with the original httpbin
implementation by tricking the stdlib net/http machinery into parsing
request bodies for DELETE requests.

This adds a new /hostname endpoint as originally proposed in #66. In
this implementation, it exposes a dummy hostname by default, and only
exposes the real hostname (via `os.Hostname()`) if the
`-use-real-hostname` flag is given on the command line.

* Fix installation of deps

* Rebuild static assets w/ newest go-bindata

* Update go versions for CI

* Fix deploy on merge

* Bump golangci-lint version