One of the major problems with `phragment.getpatch` is that it calculates the patch list when the method is called. When a fragment has a reasonable number of fragments underneath it, it quickly reaches the execution limit (and in some cases hits max_allowed_packet in MySQL).
So this method either needs to use a pre-calculated list of patches, or work in an asynchronous manner (where the caller requests patch calculation and then daemons pick the request up and handle it). A pre-calculated list of patches have the problem that we don't know what patch combinations to pre-calculate; it won't always be the last patch. We could however, combine the two methods, caching the results from an asynchronous calculation.
For asynchronous I'm thinking something like:
`phragment.startpatchcalculation` with the same input values as `phragment.getpatch`. This returns immediately with an identifier for the patch calculation work ID.
`phragment.getpatchcalculationstatus` with the patch calculation work ID returns what files have been calculated for, and what is remaining. Callers can use this to check on the process of the patch calculation (since if it's taking longer than 30 seconds, callers probably want to inform the user what's going on).
`phragment.downloadpatchcalculations` with the patch calculation work ID. When `phragment.getpatchcalculationstatus` indicates that it is complete, the caller uses this to get a list of patch URIs and hashes to apply.
@epriestley What are your thoughts?