Most tests would randomize the username when creating a
`TestClientBuilder`; make it the default, since it's a sensible choice,
and avoids interference between different tests / test runs.
A single test required an actual non-randomized username, so a specific
way to opt out from this new default behavior has been introduced.
When using the same pattern of `client.register(); client.login_*` that is used by tests in [our Acter app, strangely showed that more than one device/session had been opened](https://github.com/acterglobal/a3/issues/938).
Turns out, if the server is set up for it, according [to the spec](https://spec.matrix.org/v1.8/client-server-api/#post_matrixclientv3register) registration _is_ already a login and both device id and access token will be returned ... which are then straight-up ignored by the matrix-sdk Client and without any way of setting it from the outside, one _must_ login again, creating a second unnecessary device/session.
This PR adds an integration test case that checks that upon the minimal registration-login-flow only one device/session is found (as is to be expected from the outside), surfacing the error. It also contains a "somewhat fix" (as we need this in the app right now), but as it a) changes the behavior of the current API and b) isn't fully implementing the encryption-bootstrapping-pattern (and thus fails a different test), I'd leave it open to discussion whether that was appropriate way to go.
---
* Test showing registration-login-pattern leads to too many devices
* Fix too-many-devices-bug
* Do not panic on failure to set session, refactor and add docs
* refactor bootstrap crosssinging
* Fixup
* Use new post_login_cross_signing feature from Oidc, too
* unwrap at construction for less verbose code
* remove comment from test
* make new fn pub(crate) to fix build
Benjamin Bouvier