[WIP] Explore replacing $q with bluebird

[stacey-gammon]

If this worked, we could stop passing Promise classes everywhere, esp to our business logic classes, and just use the bluebird Promise directly.

Ideally we'd use native promises instead of bluebird but it was easier to swap with bluebird since we still use Promise.defer, and bluebird has the setScheduler functionality.

[stacey-gammon]

My main concern with this approach is how it would work if react code grabbed the bluebird promise that was hooked up globally to the angular digest loops. Would it end up hanging, waiting for a digest loop, like it does in our test suite without the no_digest_loop special handling?

That would have to be investigated. If it was the case, this is probably a no go, since it'd be too difficult to keep globally turning on and off the setScheduler and expect it to work correctly in this mixed angular & react environment.

Another approach is to create a clear separation of business logic from angular code, so angular code can wrap native promises with their own q implementation. That might be difficult given how intertwined our code it right now.

[stacey-gammon]

Closing in favor of a different approach outlined here: #13855