Add kapacitor loopback

[nathanielc]

Adds the ability to natively emit data back into Kapacitor from a task

Does this break the order guarantee? No, not anymore than you could have done using InfluxDBOut.
We can always gate loopback writes through a reorder step if it does become something that is hard to manage in practice.

Does this allow creation of infinite loops? Yes, but not within the same task. To create an infinite loop you would need to use at least two task each with a loopback pointing at the other. A warning has been added to the docs, but this should be rare.

• Rebased/mergable
• Tests pass
• CHANGELOG.md updated
• Add tests for batch/stream

[desa]

So I got a bit carried away and started playing with recursion in the loopback.

Made the tickscript for iteratively computing the square root

var tolerance = 0.0001
var sq = stream
 |from()
   .measurement('m')
 |eval(lambda: 0.5 * ("x" + ("s" / "x")))
  .as('xn')
  .keep()

sq|where(lambda: abs("x" - "xn") < tolerance)
 |log()

sq|where(lambda: abs("x" - "xn") > tolerance)
  |eval(lambda: "xn")
   .as('x')
   .keep('s','x')
 |kapacitorLoopback()
  .database('mydb2')
  .retentionPolicy('autogen')

with mutually recursive

var tolerance = 0.0001
var sq = stream
 |from()
   .measurement('m')
 |eval(lambda: 0.5 * ("x" + ("s" / "x")))
  .as('xn')
  .keep()

sq|where(lambda: abs("x" - "xn") < tolerance)
 |log()

sq|where(lambda: abs("x" - "xn") > tolerance)
  |eval(lambda: "xn")
   .as('x')
   .keep('s','x')
 |kapacitorLoopback()
  .database('mydb')
  .retentionPolicy('autogen')

and data

m s=5,x=1

where s is the value you want to compute the square root of

[desa]

LGTM! I'm excited about the types of things this opens up.

[desa]

Why didn't this need a read lock previously?

[nathanielc]

It did, but wasn't caught by the race detector somehow.

[desa]

Why was writesClosed introduced?

[nathanielc]

To safely close the writePointsIn edge we need to ensure that no more writes were happening. This meant that we needed to check a RWMutex and perform a multistage close.

The close process looks something like this:

1. Stop all writes
2. Close writePointsIn edge.
3. Wait for all forks to finish
4. Delete forks
5. Stop tasks
6. Mark task master as closed.

This should have been the process all along but previous with just the HTTP method of writing points it didn't matter. But now with the new loopback way of writing points this explicit close process was needed to prevent panics on writing to the closed edge.

In other words the HTTPD service was always closed before the TaskMaster so the fact that the Close operation wasn't safe didn't matter since writes could not come in during the close operation. But this new loopback method for writes changed that.

[desa]

That makes sense