Add POST /query endpoint and warning messages for using GET with write operations

[jsternberg]

In order to follow REST a bit more carefully, all write operations
should go through a POST in the future. We still allow read operations
through either GET or POST (similar to the Graphite /render endpoint),
but write operations will trigger a returned warning as part of the JSON
response and will eventually return an error.

Fixes #6290.

[jwilder]

Signature is getting lot of parameters (6 now). May want to refactor this in another PR.

[jsternberg]

I agree. Most of this stuff is included in ExecutionContext so that can probably just be used. We're going to have to change this at some point to include the user, so I'll change it then.

[e-dard]

@jsternberg Sending parameters on the URL is somewhat unusual for a POST request. Usually you would send the URL-encoded parameters within the body of the request.

You could achieve this by doing something like:

// client/influxdb.go

// don't add the values to u.RawQuery, then:
body := strings.NewReader(values.Encode())
req, err := http.NewRequest("POST", u.String(), body)
...

Then, in the handler where we're doing things like:

q := r.URL.Query()
pretty := q.Get("pretty") == "true"

we should be doing:

pretty := r.FormValue.Get("pretty") == "true"

which will support request that come in both via GET (with query parameters) and POST (with request body parameters).

[jsternberg]

@e-dard you're right, but we do the same thing with /write. We can support both, which is what using the form value would do, but it also makes the code more complicated since GET and POST now need to be treated differently.

[e-dard]

@jsternberg why would they need to be treated differently?

[jsternberg]

I just read the full of what you wrote and I'm likely wrong. I'll modify and try it out.

This is why skim reading isn't a real thing.

[jsternberg]

@e-dard updated, but credentials still have to be in the query url since the code for that one is shared with /write. Maybe we can update that in the future, but I think that should be good enough for this one.

[joelegasse]

URL parameters with POST is perfectly acceptable. It allows setting parameters and a payload separately. It also means the payload can be something other than URL-encoded parameters. We do this for /write: database, retention policy, and precision are set in the URL and the body is the text line protocol for the points. We just fixed a bug caused by using FormValue in the /write endpoint, and I'd rather not re-introduce it.

[jwilder]

LGTM 👍