Decommission AssetBundle Support

[sebjf]

Description

Remove support for AssetBundles and make associated improvements as per this product ticket: https://github.com/3drepo/3D-Repo-Product-Team/issues/402

Goals

• [x] Bouncer only builds RepoBundles and contains no references to the supporting infrastructure for AssetBundles
• [x] There are dedicated types for Meshes and Supermeshes

Tasks

• [x] Remove 3drepobouncerwrapper and wrapper tests projects
• [x] Remove AssetModelExport class and its integration in scene manager
• [x] Add a new Supermesh type to bouncer that is in-memory only, to be used where MeshNode instances behave as Supermeshes (i.e. MultipartOptimizer and MeshMapReorganiser)
• [x] Move rest of code away from using builder objects and use just factory methods
• [x] Move the submesh ids and mappings from MeshNode to the new type.
• [x] Make stash graph in memory only
• [x] Make MultipartOptimizer use default graph UUIDs/references, since we aren't going to commit the stash graph so theres no need to avoid x contamination.
• [x] Address https://github.com/3drepo/3drepobouncer/issues/678
• [x] See if we can delete insertBinaryFileToDatabase
• [x] Move metadata into repoAssets
• [x] Rename RepoUnityAssets to RepoAssets
• [x] Add unit tests for Mesh Map Reorganiser
• [x] Update unit tests that use the stash graph (i.e. RepoBundles tests)

Questions

1. Should we leave the MISSING_BUNDLES UploadStatus flag, given that it is hooked up outside bouncer?

Related Resources

https://github.com/3drepo/3D-Repo-Product-Team/issues/402

[sebjf]

Hi @carmenfan,

A few questions on this ticket when you have a sec!

1. I have made a SupermeshNode type that subclasses MeshNode. I will leave this even though it subclasses a Mongo BSON type as a supermesh is naturally a specialisation of submesh, and we can decide what to do about it inheriting from a Mongo type when we do the driver upgrade.

2. Similarly, I've left both the stash and default graph as the same type. This is because accesses to these go through RepoScene anyway, so I don't see any type-safety benefits of making them separate types - for now.

Do you agree, or would you like to split either of them up further immediately?

3. For flags like MISSING_BUNDLES, do you want me to leave the definitions in bouncer with a comment that they may exist in the database but are not written anymore, or just remove the definitions entirely?

4. Do you want me to look into moving/duplicating texture entries(*) so we can sort out this properly, or are we not bothered?

(*) One simple approach for example may just be to make copies of .scenes, texture Nodes in the now in-memory only stash graph. They would remain in .scene in the database for the backend, but it would mean we can free the entire graph. Or, if we think we will soon do something like atlasing, we could create a new collection for textures.

[carmenfan]

1. ok
2. yes fine as well.
3. Let's leave the definition - it will be confusing if we reuse the enum
4. If this is simple enough to do yes, if not then we can address it as part of #683. With the ever growing model size, the more memory we can work with the better

[sebjf]

(Just a note for later, but it might be worth running a migration script so we can decommission the assetsMeta API in the near future. Such a script might be feasible since iterating over the stash graph is done every time a model loads anyway at the moment!)