[FEATURE] configurable setTimeout

[runspired]

This PR enables the setTimeout instance used by backburner.js to be configurable, by modifying the use of platform to also be configurable.

The benefit of this is that users can easily switch out the setTimeout implementation for smarter implementations built on requestAnimationFrame or requestIdleCallback.

An example use case of this is ember-run-raf, which has enabled using backburner with requestAnimationFrame via a global override of setTimeout. In using backburner with requestAnimationFrame in this way within Ember applications, nothing but positive results have been noted, with the exception of an issue arising socket.io, which uses setTimeout during it's socket keep-alive sequence. Work scheduled in requestAnimationFrame is paused while tabs are inactive, leading socket.io to close the socket.

With this change, the override in ember-run-raf will no longer need to be global, allowing applications which need to use setTimeout for background tasks to continue functioning properly.

[runspired]

The test failure is simply because bind isn't available in the current test setup.

[rwjblue]

If we are going to move forward with this, we definitely need tests.

[runspired]

@rwjblue inline tests to ensure it's a function? Tests to make sure it's configurable?

[rwjblue]

@runspired - We need to have tests to ensure that if an alternate is supplied that it is used.

[runspired]

@rwjblue got it, what should I do about the bind usage (for tests)? Just use call each time instead? Upgrade the test environment? Since this is a function likely to be called decently often I figured cacheing the bound version made sense.

[stefanpenner]

We have to unfortunately assume our consumers also use the same test env. A manual closure to emulate bind should work

[rwjblue]

what should I do about the bind usage (for tests)

Don't use it 😜

Since this is a function likely to be called decently often I figured cacheing the bound version made sense.

I honestly have no clue if binding a function once and calling many times is faster than f.call(someContext) every time. If using Function.prototype.bind is actually faster, you could add a small util function that returns the bound function so that you could use Function.prototype.bind on platforms that support it.

Either way, I think we have to avoid assuming .bind is present. Ember itself is tested with Phantom 1.x, and it is reasonable for consumers to assume this is part of our SemVer guarantee (whether it actually is or not is a different story).

[runspired]

Before I saw the suggestion to just use a closure (which is now in place) I updated the travis setup to use phantom2, should I revert that or leave it?

[rwjblue]

I'd prefer to revert that for now. We can have a separate discussion/PR for that, and I don't want this feature being mired in those arguments. 😸

[rwjblue]

Also, looks like this needs a rebase due to some other changes that landed on master recently.

[runspired]

👍

[rwjblue]

OK, test is added and build is passing. This generally looks good to me (but I'm no BB expert 😝)...

@stefanpenner - Can you review?