Provide idempotency key to the task creation endpoint in an HTTP header

For resilience against transient errors, we should make sure divviup-api's interfaces are idempotent. The challenge is establishing a useful idempotency key: in this proposal, the subscriber is no longer responsible for choosing any unique task parameter like task ID or VDAF verify key. In the near term, we can accept that when task creation fails, it may leave orphaned tasks in one or the other aggregator's database, which is not a significant concern because it only costs a single database row and it should be easy enough for something like Janus' garbage collector to identify and reap the orphaned tasks. In the longer term, we can implement support for an idempotency key in an HTTP header (see draft-ietf-httpapi-idempotency-key-header for one solution strategy) that would make this endpoint properly idempotent.

Start by tracing divviup-api's task creation endpoint and reviewing the draft-ietf-httpapi-idempotency-key-header proposal. Define the HTTP-header behavior and verify that repeated task-creation requests are handled idempotently, while considering the stated orphaned-task and Janus garbage-collection context.