starttime and endtime are now based on the same time.Now() call

it turns out even a single nanosecond difference between start and endtime resulted in an additional block of timeseries data to be loaded.

As it was implemented (start and then endtime), the '''monitoring.metrics-interval''' between starttime and endtime would be wider than requested.

It seems a minor thing, but it caused API to return another block of data.

When requesting API monitoring data, it uses the endtime as the starting point for returning data (mandatory). It then continues its way backwards until it fulfils the value provided as starttime in the API call (optional).

It only stops when the starttime of the minute data stop is of an earlier or equals date to the starttime specified in the API call. Remember that the data from the API comes in slots of 1 minutes.

Here is an working example for an internal of 2 minutes:
* starttime: 2018-03-12 11:43:00
* endtime:   2018-03-12 11:45:00.000001

The API would return available data for the last 3 slots:
* between 2018-03-12 11:44:00.000001 and 2018-03-12 11:45.000001
* between 2018-03-12 11:43:00.000001 and 2018-03-12 11:44.000001
* between 2018-03-12 11:42:00.000001 and 2018-03-12 11:43.000001

So, this change now ensures the starttime and endtime values are aligned.

Author: Tulio de Souza

collectors/monitoring_collector.go

@@ -156,8 +156,8 @@ func (c *MonitoringCollector) reportMonitoringMetrics(ch chan<- prometheus.Metri
 
 		errChannel := make(chan error, len(page.MetricDescriptors))
 
-		startTime := time.Now().UTC().Add(c.metricsInterval * -1).Add(c.metricsOffset * -1)
 		endTime := time.Now().UTC().Add(c.metricsOffset * -1)
+		startTime := endTime.Add(c.metricsInterval * -1)
 
 		for _, metricDescriptor := range page.MetricDescriptors {
 			wg.Add(1)