Add tile loading events for Voxels

[lukemckinstry]

Description

Takes the following events from Cesium3DTileset and adds them to VoxelPrimitive

• allTilesLoaded
• initialTilesLoaded
• loadProgress
• tileLoad
• tileUnload

Also makes VoxelPrimitive use Cesium3DTilesetStatistics class, but only makes use of 2 of the stats in the class so far.

ToDo

• Did not carry over these event types
  • tileFailed - issues described in this comment Voxel API should conform to Cesium3DTileset interface #12297 (comment)
  • tileVisible - not sure is there is an equivalent to selectedTiles (from Cesium3DTileset) in VoxelPrimitive, if so I believe this would be simple.
• Still need to add tests, but these look straighforward to carry over from Cesium3dTilesetSpec to VoxelPrimitiveSpec.
• move code to call events out of VoxelTraversal.printDebugInformation.

Issue number and link

related to #12297

Testing plan

Many events currently fire inside of VoxelTraversal.printDebugInformation. Enable this but comment out the last line of the function which logs the debug output so you can read the output from listeners you set up to listen to the new events.

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @lukemckinstry!

✅ We can confirm we have a CLA on file for you.

[ggetz]

@lukemckinstry

tileVisible - not sure is there is an equivalent to selectedTiles (from Cesium3DTileset) in VoxelPrimitive, if so I believe this would be simple.

There are definitely visibility checks for the tiles (nodes), it's just not in a neat array like selectedTiles are unfortunately. I believe all the visibility checks happen within generateOctree– Once the else condition is reached in buildOctree and the function no longer recurses, I think that is the highest resolution node which has been marked as renderable.

[lukemckinstry]

There are definitely visibility checks for the tiles
I see now where tileVisible would fire within the generateOctree function.

For Cesium3DTileset tileVisible, the Tile is passed to the event listener so the user can glean info and modify it before the next render. For VoxelPrimitive, the spatialNode is not part of the public API, so do we want to pass it to event listener in this same way?

If not, would we want to use this event, does it make sense to raise the tileVisible event without passing any info about the specific spatialNode? (I implemented this way for now fcd9a9c)

[ggetz]

For Cesium3DTileset tileVisible, the Tile is passed to the event listener so the user can glean info and modify it before the next render. For VoxelPrimitive, the spatialNode is not part of the public API, so do we want to pass it to event listener in this same way?

It may be worth considering making the nodes part of the public API, and if they and Cesium3DTile should conform to some interface. Probably something worth noting in #12297, but a bit much to bite off in this PR. For now, I think it's fine not to pass anything.

[lukemckinstry]

This is ready for review. @ggetz @jjhembd
ToDo item

• I do not have a unit test yet for the tileUnload event. There is an existing xited out spec covering the voxel unload process. This seems like it would be the right place to test the tileUnload event.

....spoke to soon....

• Need to add unit test for tileVisible