Feature/frag loading refactor

[johnBartos]

This PR will...

• Refactor fragment-loader.js:
  • No longer listens or emits events
  • load now takes a fragment and returns a promise
    • Resolves replaces the FRAG_LOADED event, and returns onSuccess
    • Reject replaces ERROR , and returns onError, and onTimeout
    • Removes loadprogress (for now)
    • Simplify fragment cancellation check (can check fragCurrent by reference)
• Refactor *-stream-controller.js to use new promise based data flow
  • Each controller has a local fragment-loader instance
  • Calls fragmentLoader.load
  • Emits FRAG_LOADING for API compatibility
  • No longer listens to FRAG_LOADED
  • Removes logic branches handling different fragment loading scenarios (playback, bitrate test, and init segment)
  • Fires ERROR events on load error
• _loadFragForPlayback:
  • Handles loading a frag which will be buffered
  • Calls the onFragLoaded function
  • Promise resolves to call
  • FiresFRAG_LOADED event for API compatibility
• _loadBitrateTestFrag
  • Handles loading a frag for testing client bandwidth
  • Does not (!) emit FRAG_LOADED
• _loadInitSegment
  • Handles loading the init segment
  • Does not (!) emit FRAG_LOADED
• Typescript fragment-loader and xhr-loader
• Add tests

This is a big one but each task is in its own commit:

• Promisfying: 9815b3c
• Typescriptifying: 0177836

The only catch: Hls.js now relies on Promises to be present. This is probably API breaking. We can merge this into a 1.0.0 branch if we decide not to ship this in a minor.

Why is this Pull Request needed?

Making fragment loading private and explicit to the controller which requested it allows us to simplify load callbacks. Instead of having each FRAG_LOADED callback check whether it should handle the event (by checking fragment type & controller state), promises allow each controller to handle only the fragment it requested. This allows us to remove a few checks at the top of each callback. Furthermore, we can split out specialized fragment loading scenarios (bitrate test, init segment) which are not demuxed into their own functions by attaching a different .then.

In addition to code cleanliness, this new pattern is the first step in enabling LHLS. LHLS requires progressive playback, which means that we're not going to have the same event flow that we have now; a fragment will be loading, parsing, and buffering at the same time, several times during its download. Our current architecture cannot handle this because it relies on events being fired in a specific sequence to propagate fragment data. By shifting to promises we eliminate the dependency on events for propagating fragment data.

Are there any points in the code the reviewer needs to double check?

• Are there any places in which API compatibility has been broken
• Any Typescript critiques? This is my first TS PR

Downstream clone of video-dev#2123

[robwalch]

need this?