Task expiration and deletion

[inahga]

Supports #862.

Two methods are provided.

• PATCH {task_id} with one field expiration that allows free manipulation of a task's expiration date. As alluded to in Change default task expiration to None #980, there is no semantic validation of the new expiration--this can be set to whatever the user would like. Changes are propagated to the aggregators.
• DELETE {task_id} which sets the aggregators' expiration, if not already set and expired, and then tombstones the divviup-api view of the task by setting deleted_at. Currently, there is no effect of this flag--all other methods will ignore the deleted_at field.

Note that I'm assuming aggregators need to have support for the missing endpoints, otherwise we explicitly fail. I landed on this because we don't want to 'lie' to the user about deletion/expiration, since active aggregator-side tasks can still process data.

There is still more work to be done, but I'm keeping this PR from getting too long.

• Other existing task endpoints are not aware of the deleted_at field, e.g. listing tasks still presents deleted tasks.
• Need client/CLI support outside of basic definitions.
• Need UI support.

[inahga]

Note that I'm assuming aggregators need to have support for the missing endpoints, otherwise we explicitly fail. I landed on this because we don't want to 'lie' to the user about deletion/expiration, since active aggregator-side tasks can still process data.

Hmm. It occurs to me that if the helper aggregator no longer exists, e.g. because the user is turning down their own BYOH, then tasks involving the deleted aggregator will be undeletable.

I suppose I should make it such that the leader aggregator must succeed in setting expiration, while the helper can be permissive of failure. This should be fine--the leader is what drives the protocol and is what incurs most of the cost.