Consider adding max_task_lifetime to force retire a task

[wangshan]

The current spec doesn't explain how to retire or delete a task. For some use cases, it's useful to have a hard task deadline, when expired, the task and all its aggregations must be made inactive and eventually deleted. This can be a new Duration type task parameter called max_task_lifetime, or max_task_duration to avoid similar named but int typed max_batch_lifetime.

Other than the practical benefit, for clients that uploads repeatedly and periodically, this can add privacy benefit to limit the number of uploads from the same client to the same task (related to #210).

PS. I feel like "lifetime" is more appropriate for a deadline than a max allowed count.

[tgeoghegan]

This is a neat idea, especially in conjunction with the notion in #290 about clients being able to define tasks. We might think of a client sending task parameters to aggregators as implying the client's consent to those parameters, so having tasks expire and thus requiring clients to periodically re-affirm their consent to participate in a task is interesting.

[chris-wood]

I filed #299 forgetting about this issue. I think we should do this, and more see this as a minimum amount of time the aggregators must hang onto task-related data before feeling free to start discarding things.

[wangshan]

I'm writing a PR for this feature, I realised there are two things this issue is trying to cover:

1. The period that indicates a task is allowing participation. This is mainly a client-facing feature and is a max time.

2. The minimum amount of time the aggregators must hang onto task-related data. This is more of an aggregator related feature.

For 1. If we send task parameters to client for transparency, then client SHOULD check this timestamp before sending any queries to aggregators. To prevent malicious client from sending data to out of date task, aggregators should check the timestamp on these endpoint too. But this brings a lot of other issues: clock screw between client and aggregator, and clock screw between aggregators. On the collector side, aggregator cannot reject collect queries since the collect flow is asynchronous. Especially for interval based query and max_batch_lifetime > 1, collector may query a batch after the task itself is no longer active.

Based on the current draft text, I agree with @chris-wood that max_task_lifetime should be more about 2. It's more about retention of the task data and does not require any timestamp check on the task at each endpoint.