wire up INTO queries.

[DanielMorsing]

Since INTO queries need to have absolute information about the database
to work, we need to create a loopback interface back to the cluster
in order to perform them.

[DanielMorsing]

This breaks CQs in its current state. I will push a commit that fixes this later today.

[DanielMorsing]

Since the into queries broke CQs, I've moved the CQs to use into queries. I was planning on doing this in a separate PR that also implemented backfilll

[DanielMorsing]

Ready for review
@otoolep @dgnorton

[dgnorton]

+1 lgtm

[otoolep]

I am missing something context here. What is the issue we're fixing here? Don't CQs basically already work?

[dgnorton]

@otoolep The main purpose of this change is to implement INTO for a normal select statement outside of CQs.

[otoolep]

Minor: can we capitalize INTO? That gives the next a guy a clue that it's for that keyword (since the convention is we often capitalize keywords in docs).

[otoolep]

+1, once the CHANGELOG is updated.

[pbooth]

In the related issues #910 , 910 974 there is some discussion and clearly some doubt about why its important to have the ability to do a traditional SELECT INTO, or to copy series without creating a continuous query. "Why would the same data need to be in two shard spaces?" asks Paul, reasnably.

I've really missed this feature and I wonder if it s because people are using influxdb in ways that are different than the creators imagined?

I am using influxdb as the backing store for performance testing / investigation work where the final product will often be a one-page Grafana dashboard that answers a question like, "Whats the performance impact of feature X?" or "Which of these three servers has the lowest latency?"

This is happening whilst both influxdb and grafana ware being developed. AT times I come up against bugs or misisng functionality that leads me to want to install the latest copy of each. So at any time I have six different influxdbs that are a mix of 0.9.2, 0.9.3, 0.9.6 fronted by different version grafanas. I have wanted to copy series from one influxdb to another whilst:
1. deleting all zero values
2. converting from millis to micros to support better integration with other series.
3. add additional keys to support newer comparisons
4. isolate resources - move data X from server S1 to a faster server S2 so I can continue beating S1 up with unreasonable workloads and ensure my manager can view the data on a stable, responsive dashboard.

For each of these use cases a SELECT INTO feature would have been very useful. I dont thionk thats the sam ething as a continuous query