Factor out "defer" usage for better error handling

Cesium uses defer throughout the codebase as a remnant from when we were using when.js. However, the recommended best practice is to use new Promise constructor directly because it makes it much harder to let an exception escape. Functions passed to the construct should only reject the promise, never throw.

https://github.com/CesiumGS/cesium/pull/10149 excluded several specs in Cesium3DTilesetSpec, GltfLoaderSpec, TimeDynamicPointCloudSpec, and ModelExperimentalSpec which can be re-enabled once errors are better handled as a result of this change.

[lilleyse]

I’m not entirely sure yet, but I don’t think so. So far it seems it can be handled internally and we just need to move around where the caller is actually handling the promises.

Ok that doesn’t sound too bad. I was imagining that a larger restructuring would be needed.

I agree Model.js will have similar problems. What do you think the timeline is for removing it? Maybe we can leave defer there until its replaced by ModelExperimental. It’s not causing issues in the specs like the loaders are currently.

We’re aiming to remove it in June. Holding off until ModelExperimental replaces it sounds good.

[sanjeetsuhag]

@ggetz 3 areas remain:

• Resource.js and everything related to that.
• TaskProcessor.js - being addressed here: https://github.com/CesiumGS/cesium/pull/10545#pullrequestreview-1037388266
• DeferredLoading in KmlDataSource - not sure if worth doing right now, that entire system could probably be reworked. I’ll open a separate issue for that too.