Make `now` configurable so time can freeze during backburner run loop

[alias-mac]

This allow us to use fake timers, such as sinon.useFakeTimers, to check the state of the app during the run loop.

For example: if a popup is supposed to be triggered in X ms from now and it will show to the user during Y ms, then this will allow us to use fake timers to pause between X and Y and check the state of the Ember app at that exact time.

This is related with #263, #179 and #166.

If someone needs to have the backburner clock separate from the global stubbed clock (as explained in #179), then _platform.now config should be used to pass the native Date.now function.

[stefanpenner]

I think we explicitly made it work the other way... Im not sure this should be merged.

cc @rwjblue

[rwjblue]

I'm not sure I follow your concern. What use case was solved before that this does not support?

[alias-mac]

@stefanpenner our use case is simple (ability to test popups/toasts on acceptance tests) and was working on previous versions of Ember (at least 2.10, 2.11, 2.12 and 2.13). This broke our ability to upgrade to 2.14 and without this we can't upgrade to 2.15 either.

Basically the code of the toast library that we have does the following:

this._showTimer = run.later(this, () => {
  // ... shows the toast in the DOM
  this.closeTimer = run.later(this, this.close, 4000);
}, 10);

This means that we need to basically pause exactly between 10 and 4000 ms to confirm that the toast is showing the expected message to the user. I'm sure there are other use cases where you want to pause the backburner while you are testing the app in order to see if something is in a certain state at a particular time. For instance I can think of a progress bar that you might want to see updating based on time ticking every 10 seconds.

Without this fix we would probably need to:

• change our tests to integration tests where we mock the toast to check that it was called with the expected message;
• use something like a waitFor test helper that will keep probing the DOM for the toast existence, which imho will make our tests run much slower since reading the DOM is slow and we have quite some acceptance tests in our app.

Both approaches will require a substantial work to update our tests.

I personally don't see the benefit of querying the DOM, and I see reasons to test this in Acceptance tests (like taking screenshots on our tests when they fail and confirmation of what the user sees is what he/she is supposed to see and a swap/update of toast library's API - that would require updating the stubs on all integration tests), thus this solution seems more practical.

For what is worth, the solution for the problem raised in https://github.com/emberjs/ember.js/issues/14722 is as simple as:

• restoring the clock before calling the andThen. To me it is bad to create a fake clock to all acceptance tests (the way that is done in that twiddle in beforeEach), because you are faking all the clocks of the system, not just the clock that you want to affect on your particular acceptance test. In our case we have fake timers created only on the tests that are validating the toasts' messages, thus we restore the clock before terminating the test and everything is great.
• tick the clock forward and call the asserts that are inside of the andThen block, since that will move the backburner forward).

Thoughts?