Allocate sufficient time for migration processes

Makes sense. It's hard to see a use case for calling a migration outside of a batch, and if someone did they could take care of page execution time themselves. And, yes, sound point about most migration processing being outside of what counts as PHP time (except on Windows).

Looking closer, while the cron system does allocate processing time, batch API does not (presumably on the assumption that most batches will chunk operations into batches that don't require extra resources).

I opened this issue coming from #1763508: Reimplement Migrate integration in the installer, where bojanz noted "when the system is low on memory, the migration completes halfway through and the installation is completed without the complete set of content."

Yes, batches should include the sort of code that's in migrate_ui_batch(), examining the return value of the processImport() method and responding accordingly, with the result that incomplete imports will still be completed in subsequent rounds. Still, since migration is a resource-intensive and very infrequent operation, it seems like a good case for setting a high time limit to minimize RESULT_INCOMPLETE migration results, which can result from approaching the PHP time limit (see MigrationBase::timeExceeded()).

Two places we could put this. 1., before calling processImport(). 2., in processImport(), before initiating the import. Attached patch takes approach 2.

Here's a revised patch based on the suggestions in #4:

• Add a batchTimeLimit property and setBatchTimeLimit method to MigrationBase.
• Call setBatchTimeLimit in migrate_ui_batch().