Add time range to tenants

[anothertobi]

Summary

Introduces a time range for the source/target links of a tenant.

Checklist

• Categorize the PR by setting a good title and adding one of the labels:
  bug, enhancement, documentation, change, breaking, dependency
  as they show up in the changelog
• Update tests.

[anothertobi]

Draft since this does not yet handle existing tenants where the time is outside the time range.

When a tenant is created, the time of the run is used (oldTime). A subsequent run could have a time that is before the previously used lower bound (newTime).

Idea:
Set lower bound of existing tenant to newTime (move during back in time) when source and target match and no other target exists in the time range. If another target for the source exists in the time range between newTime and the upper bound of a source, create a new tenant with the lower bound newTime and an upper bound of the lower bound of the other source (-1h).

@bastjan wdyt?

[anothertobi]

related PR: appuio/appuio-io-docs#145

[anothertobi]

Decided to fail if there is an overlap in the time range for a tenant instead of covering small edge-cases.

[bastjan]

The original unique index needs dropping. Otherwise LGTM 👍

[bastjan]

Also don't forget the invoice part, from my quick reading it should just work™️ but to feel better i'd add a split timerange to one of the invoice tests https://github.com/appuio/appuio-cloud-reporting/blob/master/pkg/invoice/invoice_test.go.

[bastjan]

I forgot our discussions already but did we not say we'll create tenants from query timestamp to infinity when upserting them? 🙈

[anothertobi]

I forgot our discussions already but did we not say we'll create tenants from query timestamp to infinity when upserting them? 🙈

I think we decided on the default of -infinity, infinity+ or fail because we can't guarantee queries to be run in order.

[bastjan]

Must be rebased, otherwise LGTM