Remove all expired allocations for a client when none specified

[anorth]

This raises a bit of a question about the return value when no allocation IDs were specified. If this were a separate method, maybe we'd return the list of removed IDs. In either case maybe we'd like to return the total datacap reclaimed. I've taken the simplest possible path here of returning nothing.

We could merge these into a return value that includes all these, like:

{
	specified_allocations: BatchReturn // only non-empty when specified
    found_allocations: Vec<AllocationID> // only non-empty when none specified
    datacap: DataCap
}

What do you think @ZenGround0 ?

Closes #606.

[ZenGround0]

I like the proposal. I've been thinking it will work generically to use the batch info as a field to index into the others alongside it and I believe this is an example of that. The only change I would make is return a batch info with success codes for every allocation successfully in the unspecified case. This way we maintain the relationship of fields of the return value across the specified and unspecified cases.

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (decouple-fil+@f8847e0). Click here to learn what that means.
The diff coverage is n/a.

❗ Current head bfb41af differs from pull request most recent head 2b2d013. Consider uploading reports for the commit 2b2d013 to get more accurate results

@@               Coverage Diff                @@
##             decouple-fil+     #671   +/-   ##
================================================
  Coverage                 ?   84.61%           
================================================
  Files                    ?       95           
  Lines                    ?    19028           
  Branches                 ?        0           
================================================
  Hits                     ?    16100           
  Misses                   ?     2928           
  Partials                 ?        0           

[anorth]

return a batch info with success codes for every allocation successfully in the unspecified case. This way we maintain the relationship of fields of the return value across the specified and unspecified cases.

I'll do this, but it can only ever be an array of ExitCode::OK the same length as the allocation IDs. Since this is an infrequent method, the result size probably doesn't matter too much, so I'll return exactly the same info in both cases: the IDs considered and the status codes and datacap, even though some can be inferred from how the method was invoked.

(Gas will be the only limit on the amount of work this could do, with large enough state).

[ZenGround0]

Since this is an infrequent method, the result size probably doesn't matter too much

The way batch info serializes all these ExitCode::OK's is by incrementing the value of the single integer success count field, so this should be efficient.