Performance: use requestIdleCallback for lazy execution

[kepta]

This pull request adds the ability to schedule callbacks smartly. Currently, all of the callbacks are executed with same priority. We need a way to prioritise them. Fortunately browsers have reached a consensus and given us an API called requestIdleCallback exactly for this.

I have added a shim for browsers which don't support it. On paper the performance should not degrade for browsers which fallback to shim, since it is a simple timeout.

Things improved.

1. Ignore duplicate entities
   iD simply parses all the entities and sometimes they happen to be already parsed. This becomes a problem when dealing with fat relations/ways, which span across multiple bounding boxes and iD has to waste time parsing them again. In this PR, I have added a check for entities which have already been parsed.

2. Scheduling parsing as a low priority task
   Javascript handles fetch request async, but the problem is when the data reaches the client and the client has to parse it. For e.g. you are panning the map and the javascript decides to parse the data right away. This leads to a stutter and lag for the end user.
   To mitigate this, fetching and parsing have been converted to a low priority task, (here and here) which drastically improves the responsiveness of the application.

3. Parsing in small chunks
   Even if we schedule a task as low priority, when it executes for a long time it will cause the application to stutter. The way out of this would be to break it into smaller chunks and use the IdleDeadlline API to figure out when to stop and resume the work. Relevant code here and here.

4. Scheduling the redraw
   iD's redraw is one fat function and if it gets executed at the wrong time, there is a noticeable stutter.
   The solution here is to wrap it within and idleCallback, so that the timing is scheduled properly.

5. Replacing throttles and debounces with requestIdleCallback
   I have naively added requestIdleCallback to some part of the code, labels.js, background.js,
   I am not sure if it fits well :P @bhousel ?

Other things which can be improved

Layer rendering
I tried to break these guys, but failed. The idea is to schedule them as a low priority task. Which would drastically improve iD's responsiveness. But they are too coupled and iD simply acts like drunk if I try to call them lazily.

svgTagClasses
I find this code quite confusing and complex. It also takes some 200ms to compute. We should break it down or optimise it.

Profile comparison
Over here I have compared the loading profile before and after. Notice the smaller chunks efficiently spaced.

Comparison Optimized version vs Current iD master

[kepta]

@bhousel this is good for review.

[bhousel]

Wow this looks excellent, and the changes do make the app much more responsive!

From the "to be improved" section:

• async layer rendering might not be possible, I'm not sure. The layers "act like drunk" because they're being drawn with a slightly wrong projection, which then catches up whenever the next non-differenced redraw happens.

• svgTagClasses definitely should not be taking 200ms to execute, so we can look into that as a separate issue. That code is kind of complicated because osm tags are complicated.

[bhousel]

The test failures for loadEntity and loadEntityVersion make sense. I think I can fix it..

[bhousel]

This is working ok now. I did some editing with it today and will do a bit more tonight just to test. It seems good in Chrome, Firefox, and Safari. I'll double check with Edge and IE (but if PhantomJS tolerates the shim, I'm sure we are in good shape).

I'm really excited about this for a few reasons. One is because parts of iD got a lot faster, but even more than that, it opens up a lot more opportunities to improve performance - there are still a bunch of easy wins.

• feature filtering and classification can definitely be deferred (this is a sizeable chunk of time in redraw())
• we haven't added this yet to other services like nominatim or mapillary
• can background load large multipolygons to complete them
• can think about how defer the layer rendering
• of the render functions, labels are taking up a lot more time than they should - we can defer/cache label placement instead of redoing it each time.

[JamesKingdom]

@kepta This is amazing 😮 , it feels so much more responsive 👍