GitLab

We want it the revision list to happen in `history`
to allow tshistory_formula to use it at will
(and in a different way).

This can achieve a nice performance improvement (time and memory wise)
since we can query less series.

Performance implications:

historycache:
DELTA all value dates 0.5080251693725586
DELTA 1 day  0.04896068572998047

prune:
DELTA all value dates 0.5207259654998779
DELTA 1 day  0.03272509574890137


We lose a bit on the commplete horizon but get nice benefits on the
small one. We might want to rewrite the prune function for speed ...

Also move `_revision` to the private methods zone.

This opens the door to a new `revisions` parameter
which allows to pass a precomputed revisions list.

We introduce a generic `historycache` providing
`get` and `staircase` methods.

The `historycache` object embeds the output of a call to `history` for
further use.


Performance implications:

correctness:
DELTA all value dates 1.174530267715454
DELTA 1 day  0.05773115158081055

historycache:
DELTA all value dates 0.5080251693725586
DELTA 1 day  0.04896068572998047

On the whole horizon we get a nice speed up (> 100%) and even the one
day horizon gets slightly faster. This is good.

We get the base dates from the current series value dates.
For each of those we query one point, then concatenate
the result.

Conceptually much simpler to grasp.
Bonus side effect: staircase discrepencies of formula vs alias
extensions have disappeared.

Performance implications:

base:
DELTA all value dates 0.9304628372192383
DELTA 1 day  0.10948061943054199

correctness:
DELTA all value dates 1.174530267715454
DELTA 1 day  0.05773115158081055

So on the whole horizon we are a tad slower but there is an
interesting speedup already in a well-bounded case. This is not bad.

It does not make sense to expose them.

Convenient to have an history as a dataframe.

The only untested command is of course broken.

Specializers might need to build their own insert variant
using this.

This will help specializers provide alternate/extended metadata.

We can leave the old ones in place.

This is because of history/diffmode.

... since we only get one at a time.

sql is such a fuss...

Rather than just crashing ...
This typically happens when there is a discrepancy between
some installed lib version and a required version within
a dependancy.

This should be a one-shot operation.

Since straight out of the db we only get an offset,
and the utc timezone is quite implicit. We want it to be explicit
since pandas can change it interpretation from version to version
(e.g. .23 to .24 in a .loc in the presence of a datetime with offset
but no tz).

(we know it is utc because:

 * postgres is configured (see conftest) to UTC
 * we insert as utc
)