Have cargo-spatial generate component-id be aware of existing schema components.

[jamiebrynes7]

In the Spatial.toml config - we have access to all the schema paths where components can be defined.

This means that we can exclude random draws that collide with existing components.

Big decision is whether to:

• Parse the schema files manually, through regex or tokenization.
• Invoke the schema_compiler to generate the bundle.json and read the IDs from there. This temporary json file can be discarded after the JSON is parsed.

At first glance, I lean toward the latter option

[randomPoison]

I'm not sure how necessary this is in practice. I attempted to do some analysis on the probability of a collision given randomly selected component IDs, and found that there was a 0.18% chance of collision with 1,000,000 components (see my original post for more). Assuming my work is correct (which it may well not be 😅), the probability of collision is likely low enough to not be worth the effort of checking for duplicates.

Even then, I don't think detecting component ID collisions in the project would be a sufficient solution. Even if a generated component ID doesn't collide with any component IDs in the current project, it's entirely possible for that ID to collide with a dependency that gets pulled in at a later date. This is the main issue that I highlight in the forum post I linked above.

As such, the only practical (decentralized) solution is to increase the range of valid component IDs that SpatialOS will accept in order to keep the probability of collision low. That's going to require a change to SpatialOS itself, and isn't something that we can (or should) address in the SDK in my opinion.