Add uint support into the write protocol

[jsternberg]

• Rebased/mergable
• Tests pass

[rbetts]

If this code is sufficient to parse incoming uint64 in wire protocol format, I'd like to have a flag to keep it disabled on master until we are ready to support uint64 through the whole stack. There are concerns that we will cause errors with Chrongraf / Kapacitor if we start storing and returning uint64 before we can move the change through the entire TICK stack.

[rbetts]

This check is redundant with the initial check at line 833?

[jsternberg]

I don't believe so. The check at line 833 prevents a person from writing m=-. This checks to make sure a negative wasn't used while looking at an unsigned integer.

[rbetts]

I might be reading the test incompletely - but need to be sure we have tests for a negative unsigned int (error path), for max value, and for something greater than the max value.

[jsternberg]

I'll add those.

[jsternberg]

I wasn't planning on having this merged until the query engine stuff was done, but I didn't think about the other applications. Should I build it as a configuration option or some compilation switch? I can also just block all incoming writes of unsigned with no compilation switch and no configuration option.

[jsternberg]

It also may be difficult to have a switch that enables this. The section of code that does the parsing doesn't really have access to any configuration and catching it later than that would probably add some undesired overhead.

[phemmer]

also is there any planned way to be able to change the type of an existing field?
I'm just imagining the scenario in telegraf where the various input plugins are storing their types as uint64, and the telegraf marshaller is sending them as signed integers. But once this PR is merged, and the telegraf marshaller is changed so that uint64 is actually sent as an unsigned integer, lots of writes will start failing because of conflicting field type.

[rbetts]

@phemmer The ability to retroactively rewrite field types is not in scope. We are thinking through issues like the one you've raised but our immediate goal is to get to a functional uint64 field type.

[rbetts]

@jsternberg I would avoid a configuration parameter - as this won't be long lived toggle once everything is done. A command line flag or environment variable might be preferable. I would like to get these bits landed in reasonable chunks on master.

[jsternberg]

@rbetts done.

$ go install ./cmd/influxd
$ influx
> create database db0
> use db0
> insert cpu value=1u
ERR: {"error":"unable to parse 'cpu value=1u': invalid number"}

> exit
$ go install -tags uint ./cmd/influxd
$ influx
> use db0
> insert cpu value=1u
> exit

[jsternberg]

I need to fix the tests since they fail since uint support is turned off. I'm also adding some additional parser tests for uint64 on top of the existing ones.