Previously, floating point precision was unbounded. This commit
introduces some sensible precision limits to better emulate real world
data.

By utilizing the spf13/viper library, this commit enables all command line
flags to be set by using a configuration file (i.e. `config.yaml`) which
should be located in the root directory of the command.

The new query fetches the last location of a single truck referenced by the
truck name. Truck name will be generated randomly from the scale which
represent the number of trucks currently available.

Update README to show examples from IoT

Previously Travis was only running Go with modules test with just
1.11.x, instead of with both 1.11.x and 1.12.x. This change makes
each job separate so allow 3 latest versions of Go are tested.

Previous change made to the query caused ambiguity issues in the GROUP
BY clause. Since we have different cases for SELECT columns, this change
uses SELECT clause index numbers.

Tags used to be only string values but with recent changes, they get
their types correctly inserted into the schema. This commit does that
for jsonb tagsets, using number values for corresponding values and
strings for everything else.

This change should put the query on equal footing with the Timescale
version of the query because the time interval handling was pushed to
the query engine but now it should be handled in query generation.

This is a second pass at optimizing the queries, mainly includes
filtering out trucks with NULL valued names for better performance.

The time format used for Influx was the same as RFC3339, so rather than
redefining that format ourselves we just use the provided constant from
the `time` package.

The GET method allows only read-only queries to be issued, for
the iot use case we need to issue a SELECT INTO query. The POST
method of the InfluxDB API accepts both write and read-only queries.

Added first pass of Influx queries to query generator with
accompanying unit tests.

Tests are written to cover the new code and the file format
for ClickHouse and Postgres/TimescaleDB is updated to have the
tag types in the header

Changes are done to the Point interface where tags are
no longer just strings, and serializers for the different databases
are modified to serialize the tags depending on their type.
For TimescaleDB and Postgres it doesn't matter which type is it,
for InfluxDB the tag is serialized as a field.

NormFloat64 returns a value in the range of [-math.MaxFloat64,
+math.MaxFloat64] which means the current load value can be negative
which it should not be. Changing that function to be Float64 which should
return a value in the range of [0.0,1.0).

This change fixes aforementioned flags whose implementations were
commented out and not working properly.

Previous description referred hosts which are relevant only for the
devops use case. With new use cases added, description had to be changed
to include them as well.

A loading worker can be configured to have a minimum interval
between two batches being inserted. Configuration is optional,
if not configured batches are inserted ASAP. Intervals are expressed
in seconds.
Interval can also be configured to support range sleeping intervals.
The sleep regulator is in charge of putting the calling goroutine to
sleep

Previous implementation used the value `NULL` when inserting missing
values into jsonb column. This commit fixes that to the correct value
`null`.

Adding the necessary boilerplate for supporting the queries of the new
IoT use case and implementing the first versions of them. A single pass
of optimizations has been done but more optimization passes are needed
by a TimescaleDB query specialist.

Since strings.ReplaceAll was only added in 1.12, it is not usable
for all the Go versions we currently support (1.9+). Even if we
were to drop some of the older versions we support, like 1.9 or 1.10,
it still would not compile on versions < 1 year old. So for now,
we'll use the old way.

With the introduction of the possibility of missing values
in the IoT use case, the serializer for InfluxDB needs to be made
aware and skip those tags and fields in order to generate proper
Line Protocol inserts

Fuel state range changed from 0.0 - 100.0 to 0.0 - 1.0 to better reflect
real world (car gauges report from Empty to Full). We also add refueling
the trucks when the state goes under minimum value.

Previous implementation assumed devops use case by default. Here we
refactor to support multiple use cases and add the initial iot use case
query generator for timescaledb database.

IoT data can contain empty field and tag values. We need to support that
in the data loaders to be able to load the data correctly into the
database, in this case Timescale database. We also add some tests to
verify that empty field and tag values are stored correctly.

IoT data sets contain a lot of irregularities like lots of gaps, out of
order entries, missing entries, zero values etc. This change updates the
data generator so it can create data sets which contain these features
in a deterministic way.

This first version of the data generator behaves similarly as the devops
use case and does not contain any data irregularity features which will
be added in a future commit.

This improves code quality by extracting the common parts of the logic
which can be reused for multiple use cases. First step in to creating
data generators for the next use case.

When using the `pgx` sql driver, running the query does not wait for a
response from the server. In order to verify that the query has returned
complete results, we must run `Rows.Next()` until it returns false
meaning we have fetched all the rows from the query result. Note that
this behavior is different than the current implementation of the `pq`
driver.

Previously, the -n flag sent its data to the "max-queries" variable, which results in an unknown variable name when running the script because the python variable used to generate the run script is 'limit' (see line 163). "Max-queries" is only applicable as a flag for the tsbs_run_queries script, i.e., "--max-queries=###".