Logic for generating unique matrix IDs for SSO users could fail

[clokep]

This comes from a conversation at #8801 (comment)

The current logic for generating unique matrix ID is something like:

1. Get SSO attributes.
2. Pass SSO attributes to mapping provider to get a matrix ID localpart.
3. If the user exists, go back to 2 and append how many times we've attempted this to the localpart.
4. If this has been attempted 1000 times, fail.
5. If a unique user ID is generated, register the user and associated it with the SSO attributes.

A couple of odd things:

• The 1000 is arbitrary but seems rather high (we would waste a lot of processing doing this loop 1000 times).
• Can we improve this logic so you don't just give up after a certain number of iterations?

It is worth mentioning that depending on the SSO configuration and mapping provider used this might not be an issue (e.g. if you're in a corporate environment with unique email usernames and use the username as the localpart, they should never conflict). This really only happens if whatever attribute you're using from SSO can conflict (maybe you're using first name and hire a lot of people named "Erik", you'd end up with @erik:foo, @erik1:foo, .... @erik999:foo and then you can't hire more Eriks.

[clokep]

Note that the crux of this is that we do localpart += number_of_failures if failures is non-zero.