First draft to purge high volume data on an hourly basis.

This makes the assumption that we do not need NotificationHistory, we will need to ensure that for HighVolumeServices we do not recalculate the stats tables, either in the reporting_tasks nor in the commands.
The strategy to migrate to using this code is still up for design.
We will need to consider:
 - how to purge the data, safely, efficiently.
 - ensure we get the counts right for the stats table, the ft_notification_status table is particularly tricky, because as a notification moves from created -> sending -> delivered the row counts change for each status type. One idea is that we only write the `delivered`, `temporary-failure` and `permanent-failure` status into the table.

This is not production ready but just a draft to get the conversation going.
I also have an idea to stop returning "todays" notification data for HighVolumeServices on the dashboards/usages (except platform_admin) until this code is ready.

migrations/versions/0319_high_volume_service.py

@@ -0,0 +1,27 @@
+"""
+
+Revision ID: 0319_high_volume_service
+Revises: 0318_service_contact_list
+Create Date: 2020-03-20 08:53:22.624516
+
+"""
+from alembic import op
+import sqlalchemy as sa
+from sqlalchemy.dialects import postgresql
+
+revision = '0319_high_volume_service'
+down_revision = '0318_service_contact_list'
+
+
+def upgrade():
+    # ### commands auto generated by Alembic - please adjust! ###
+    op.create_table('high_volume_service',
+                    sa.Column('service_id', postgresql.UUID(as_uuid=True), nullable=False),
+                    sa.PrimaryKeyConstraint('service_id')
+                    )
+    op.create_index(op.f('ix_high_volume_service_service_id'), 'high_volume_service', ['service_id'], unique=True)
+
+
+def downgrade():
+    op.drop_index(op.f('ix_high_volume_service_service_id'), table_name='high_volume_service')
+    op.drop_table('high_volume_service')