Currently, the process of loading a tile is split into two parts:

Future-based load pipeline

This happens almost entirely in a worker thread, and consists of:

1. A network request to get the tile content.
2. Parsing of the tile content.
3. Loading additional network resouces (e.g. textures external to the glTF).
4. Decoding images (JPG, KTX2, etc)
5. Decoding geometry (Draco, etc.)
6. Creating "load thread" renderer (e.g. Unreal) resources.

At the end of this process, the Tile is in the ContentLoaded state.

Main thread update

This happens during tile selection in the main thread. Whenever we visit a tile in the ContentLoaded state, we do some additional processing and immediately (synchronously) move it to the Done state. The work done here consists of:

7. Updating the main-thread Tile data structure with new information loaded in the background (e.g. new child tiles, new bounding volume).
8. Creating "main thread" renderer (e.g. Unreal) resources.

#473 suggests separating step 1 from the rest, so that we can, say, have 20 network requests in flight at once but use a smaller number of threads for the CPU work in steps 2-6.

But this issue is about step 8. cesium-native basically assumes that ContentLoaded and Done are equivalent for selection purposes, because a ContentLoaded tile can and will be synchronously moved to Done. We should allow more flexibility in when this happens. We don't need to do it for every tile we visit; only tiles that we're actually going to render. And conversely, too many tiles sometimes hit the ContentLoaded state all at once, causing noticeable rendering pauses as we create renderer resources (including uploading data to the GPU) all at once.

With more flexibility, we can avoid eagerly creating GPU resources for tiles we're unlikely to need. And we can also throttle and prioritize resource creation to avoid major frame rate drops.