adding initial schema/mapping support for tenants

This commit includes a whole bunch of new schema changes in schema.cql. The
only thing implemented and tested so far is the tenants table. There is some
support for creating and fetching tenants.
make the interval more strongly typed, add javadoc

The schema has been modified such that the aggregation_template.interval field
is now a tuple. The map key in tenant.retentions is also a tuple now as well.
That tuple consists of the metric type and the interval. At some point we may
wind up replacing these tuples with UDTs.
initial mapping support for numeric_data table and store interval in single column

This commit introduces NumericData with a couple unit tests for exercising
basic reads/writes and mapping data. There is also some work around attributes.

I have updated the schema  again, storing the interval as a single column/field.
It is easier to manage that way. I have also introduced the Interval.parse
function for parsing strings into Interval objects.
use new C* 2.1.1 sytax for adding attributes

The new supported syntax makes its easier to add new attributes since we can
now pass a whole map which will be additive. Previously passing an entire map
would be result in overwriting an existing map.
some initial support for storing/retrieving aggregated metrics
add mappes for tenant and numeric data queries

This commit also makes inserting a tenant a conditional update so that we can
prevent overwrites.
get integration tests back working and remove using of DataAccess class from MetricsServiceCassandra

MemoryMetricsService is broken state. It still needs to be updated to work with
the new NumericData class in place of RawNumericData.
Make MemoryMetricsService work with NumericData
add tenant_id to counters
replace DataAccess with DataAccess2
add NumericData.setTimestamp convenience method

I added the convenience method because most of the time we probably won't need
to worry about UUIDs. This required moving TimeUUIDUtils and a couple
dependencies to the core-api module.
try to get travis-ci working with C* 2.1.1
move the :before-install section before :services
try taking out :services since we are not using a stock C* install
initial support for storing attributes for numeric data

Best explained with a couple examples.

POST /rhq-metrics/metrics/numeric

{
  "tenantId": "rhq-metrics",
  "name": "M1",
  "attributes": {
    "description": "Test metric for storing attributes"
  },
  "timestamp": 1415129932180,
  "value": 3.14
}

The request body includes tenantId which will soon be required. Most
importantly, notice the attributes property which is itself an object whose
values should be string.

Here is a second, slightly different example.

POST /rhq-metrics/metrics/numeric

{
  "tenantId": "rhq-metrics",
  "name": "M1",
  "attributes": {
    "units": "IBU",
    "env": "dev"
  },
  "data": [
    {"timestamp": 1415128240771, "value": 1.1},
    {"timestamp": 1415128270618, "value": 2.2},
    {"timestamp": 1415128293388, "value": 3.3}
  ]
}

Here we submit multiple data points. Because attributes apply to the whole time
series, all of the data points for the M1 metric will have the units, env, and
description attributes.
do not use hard coded keyspace name when looking up UDTs

We use different keyspace names depending on the environment in which we are
running, so the keyspace should not be hard coded anywhere.
allow storing attributes without any data points

Best explained with an example,

POST /rhq-metrics/metrics/numeric

{
  "tenantId": "rhq-metrics",
  "name": "M1",
  "attributes": {
    "host": "svr1",
    "active": "true"
  }
}
first, rough cut at support for tags

This commit adds some initial support for adding tags by date range and for
querying by a single tag.

Here is an example of adding tags,

  POST /rhq-metrics/tags/numeric

  {
    "metric": "M1",
    "tags": ["test1", "test2", "test3"],
    "start": 1415108444636,
    "end": 1415744754582
  }

and an example of querying by tag,

  GET /rhq-metrics/tags/numeric/test3
initial support for querying by multiple tags

Here is an example request,

  GET /rhq-metrics/numeric?tags=tag_1,tag_2

and the returned json looks like,

  {"M2": {
    "tenantId": "rhq-metrics",
    "name": "M2",
    "attributes": {},
    "data": [
      {
        "timestamp": 1415717835531,
        "value": 2.1
      },
      {
        "timestamp": 1415717880887,
        "value": 2.3
      }
    ]
  }, "M1": {
    "tenantId": "rhq-metrics",
    "name": "M1",
    "attributes": {},
    "data": [
      {
        "timestamp": 1415128240771,
        "value": 1.1
      },
      {
        "timestamp": 1415128270618,
        "value": 2.2
      }
    ]
  }}

The query operation performs an intersection. Only those metrics that have all
of the specified tags will be included in the results. All of the tagged data
points are included without duplicates. Consider metric M1. Let's say it tagged
data points p1 and p2 with tag_1, and it tagged points p2 and p3 with tag_2.
Then p1, p2, and p3 will be included in the results.

The returned json is a mapping of metric names to data. It is redundant to
include the tenantId field for each metric since it will be the same for all.
Notice that the attributes property is empty. This is for a couple reasons.
First, I am using the NumericDataOut class for results, and it includes an
attributes property. Secondly, the tag queries search against the tags table,
and attributes are stored in the numeric_data table. I am not sure that there
is a good way to include attributes, so I am inclined to exclude them from the
results.
initial support for tagging individual data point

to add the tag(s),

POST /rhq-metrics/tags/numeric

{
  "metric": "M1",
  "tags": ["test4", "test5"],
  "timestamp": 11415717856463
}

and to query and filter by tag(s)

GET /rhq-metrics/tags/numeric/test4

or alternatively,

GET /rhq-metrics/metrics/numeric?tags=test4,test5