Issue #97, #98: Aggregate job info per day and per week as part of JobPr...

...ocessing Step in the ETL. Also enable a rest api to fetch this aggregated app info
We should add a comment explaining how we're using the TTL here and why we're dropping older data.
It will be hard to infer from the code that there will be a column per job for each flow just so that we can check if we've see the job already to get an accurate count. We assume that no flow runs longer than the TTL time and once we have an accurate count, we don't need the job IDs themselves to report the data (the counts themselves are stored elsewhere).
I'm even wondering if we want to use a different column family name to avoid confusion with other raw columns that we certainly do want to keep.
Unsuspecting code change later could end up using the same raw column, only to find out later in production that the data is dropped.
Perhaps we want to call this a 't' (for temp) or 's' (for scratch) or something like that.