Reverse proxy timeout smaller than php max_execution_time. Batch API broken

First off, if you have huge migrations to run, I strongly recommend reading https://www.drupal.org/node/1806824. Drush ftw.

I'm a little reluctant to add something to address such a narrow use case (if I'm not mistaken, you're bumping up max_execution_time to a large value to minimize batch overhead?). That being said, if you want to pursue this, a couple of comments:

1. The test failure is telling you something - my best guess is that ini_get('max_execution_time') in the testbot is returning NULL and you need to handle it.
2. If you're introducing a migrate-specific variable, its name should reflect that (e.g., 'migrate_batch_max_execution_time').

I came across this issue on a particular AWS setup.
@mikeryan - I think the actual issue is that max_execution_time needs to be reduced, otherwise the batch job runs too long and the gateway times out before it can finish, so you never get to the next one.
Drush could solve this of course, but you don't to have a huge migration to encounter the problem - any migration via UI that has more than one batch would fail.

In my case it was easiest just to reduce php's max execution time via php.ini, since I had access to the web server but not the reverse proxy.