Mitigating data loss and delays due to batching

[alexmturner]

While batching helps reduce report volume, a simple implementation would risk data loss if the user agent shuts down before a batch is complete. This is especially a concern for reports issued by the winning bidder of a FLEDGE auction, as they could be triggered by window.fence.reportEvent() substantially later, see here for details. Batching would also necessarily delay reports until the batch is complete, again this is especially a concern for the winning bidder case.

To mitigate these concerns, we could consider modifying the batching scope. For example, we could batch contributions conditional on a window.fence.reportEvent() call separate from other contributions from the winning bidder. We could also consider persisting any pending contributions to disk to avoid data loss, allowing the batch to be processed when the user agent starts up next.

[alexmturner]

Partially completed in #40. However, the risk of data loss due to an ongoing auction or shared storage operation is still possible (albeit much reduced).