Currently we pass in null. However, from the spec:
<domain:acDate> element that contains the date and time of a
required or completed response. For a PENDING request, the value
identifies the date and time by which a response is required
before an automated response action will be taken by the server.
For all other status types, the value identifies the date and time
when the request was completed."
- https://tools.ietf.org/html/rfc5731#page-16, section 3.1.3
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139363370
HostResource and DomainApplication are not transferable, (or at
least, not directly in the case of hosts) and have no need for
the TransferData field. In a flat-flow world, we can push it down
to where it's actually used.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=139201423
This will make potential issues a little nicer to debug in the future, because
the person hitting these endpoints manually will immediately know why they may
not be kicking off a [] console as might be expected.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134840223
This applies lessons learned from the async batch DNS refresh action, in
particular making testing more robust.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134833523
This allows handling of N asynchronous deletion requests simultaneously instead
of just 1. An accumulation pull queue is used for deletion requests, and the
async deletion [] is now fired off whenever that pull queue isn't empty,
and processes many tasks at once. This doesn't particularly take more time,
because the bulk of the cost of the async delete operation is simply iterating
over all DomainBases (which has to happen regardless of how many contacts and
hosts are being deleted).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133169336
