[MM] Sensible strategy for room IDs

[fiban-havok]

The current version of matchmaking doesn't use room IDs - it identifies rooms by their connection string on the basis that two rooms cannot have the same connection string at the same time. This is simplistic since we might want to a) change connection string after room creation and/or b) reuse the same connection string for two different rooms existing in different moments. We can definitely improve on this but it's not really clear what's best.

A better solution is assigning user-specified room IDs to each new room (like Photon), keeping the connection string separate and mutable. This also enables scenarios where e.g. a host and a client can agree on the room ID offline and use it as a key to connect to each other (notably, this is what SpectatorView could do). The problems with having user-specified IDs is that the application must now care about passing unique IDs, and the backend must enforce uniqueness - which is very difficult if the backend doesn't have a central authority. Also, some backends (e.g. Steam) do not allow users to specify room IDs.

The former API version had string IDs generated by the matchmaking implementation. This solves the uniqueness problem but forces users to implement an additional mechanism to share the generated room ID at runtime, which is inconvenient especially given that matchmaking is used specifically to get a way to share info at runtime.

A user-specified ID can be "emulated" by using a user-specified attribute instead. So a client looking for a specific room would search for a specific attribute value. Here users have full responsibility of enforcing uniqueness - the backend won't help nor care. Also this only works if all rooms are public and searchable by attributes.

[stkenned-havok]

All points still valid, but our implementation has changed a little. #48 added guids to rooms because it's the easiest way to handle mutation & duplicate handling. The guids are internally generated internally each time a room is created.
Now that discovery is separate from joining, perhaps clients could join each other with a preagreed connection string instead of a room id?

[fiban-havok]

clients could join each other with a preagreed connection string

The crux of the issue is that you can't always preagree on everything needed for a connection (e.g. IP address). So apps will still want some way to go from an arbitrary pre-shared string/ID to an established communication channel. Exposing a connection string is useful to support a variety of network backends but doesn't solve this problem.