[fm] perhaps `SitrepBuilder` should not return an error on UUID collisions

[hawkw]

As I mentioned in @mergeconflict's PR #10294, the current code in SitrepBuilder for requesting alerts/support bundles and adding ereport associations will generate a UUID for the new thing, try to insert it into an IdOrdMap, and returns an error to the caller if the UUIDs collide. This is a bit sad. As I wrote on Dan's PR:

This isn't your fault (since this code is just mimicking what I did in request_alert), and probably shouldn't be changed in this PR, but looking at this again, I'm starting to wonder if the way I did the corresponding code in request_alert is really the right thing. It seems a bit unfortunate to return the error to the caller just because this method generated a colliding UUID, which the caller had no control over.

I wonder if we ought to make this infallible, perhaps by just having this code generate a new UUID and try again if it encounters a collision. In general, we assume that generated UUIDs won't collide, so it's probably also more or less fine to panic here, but I'd rather not do that, as it's almost as easy to just recover from the collision by trying again. Again, this is probably something we should change for all the sitrep builder methods that generate IDs for things and try to put them in maps...

Originally posted by @hawkw in #10294 (comment)

[hawkw]

perhaps this is really more of an non-important non-blocker, since, you know, basically all our code assumes UUIDs never collide...