Upgrade EarningsTracker to make date-based income/expense available

[ksedgwic]

Current Earnings Tracking:

Currently fee income from routing and expense due to rebalancing are held in the EarningsTracker table on a per-peer basis:

			CREATE TABLE IF NOT EXISTS "EarningsTracker"
			     ( node TEXT PRIMARY KEY
			     , in_earnings INTEGER NOT NULL
			     , in_expenditures INTEGER NOT NULL
			     , out_earnings INTEGER NOT NULL
			     , out_expenditures INTEGER NOT NULL
			     );

Problems:

1. Ancient data can dilute/overwhelm current data

Long running channels have income/expense data dominated by old accumulated data. Since channels and peer environments change over time this may not provide the best information for current decisions.
Related:

• 0.11B not rebalancing because 0.10 spent lots of money rebalancing #97
• https://github.com/ZmnSCPxj/clboss/pull/143/files

2. Users would like income/expense reports for specific periods of time

Would help answer questions like:

• How is my node changing over time?
• What was the effect of the change I made last week?
  Related:
• Boss/Mod/Tally.cpp: Implement clboss-tally. #142

3. Doesn't "heal"

This is sort of a special case of #1 ... if a bug (ie #222 ) causes distortions (either actual or measured) it would be really nice if the instance "healed" over time and converged on sensible decisions ...

Possible solutions:

1. Expunge old data from the EarningsTracker table. I hate removing data ...
2. Make all earnings and expenditures timestamped. Makes table really big, queries take longer ...
3. Time buckets

Time buckets

Add a time_bucket field to EarningsTracker:

CREATE TABLE IF NOT EXISTS "EarningsTracker"
(
    node TEXT,
    time_bucket INTEGER,
    in_earnings INTEGER NOT NULL,
    in_expenditures INTEGER NOT NULL,
    out_earnings INTEGER NOT NULL,
    out_expenditures INTEGER NOT NULL,
    PRIMARY KEY (node, time_bucket)
);

When earnings or expenditures are being reported, the current unix timestamp is divided by the number of seconds in a day to derive a "time bucket".

When a query is made for income/expense it can specify a desired time bucket range (or all if the current behavior is desired).

We can consider expunging/archiving old data in the future.

[ksedgwic]

Closing as fixed