[2.x] Update username when updating user entity

@Anas_maw: Totally makes sense to allow auto-updating the username, when the account is changed. But shouln't it better be called "Update username, if eMail address is changed"?

Any other change in the user account shouldn't affect the user name update, right?
Also I think we should discuss, if updating shouldn't be the default behavior, instead of having it the other way around, which would keep an outdated email address as user name then?

@Anas_maw: As the related issue 🐛 Switch to hook_user_presave() for setting username Needs work is unresolved for years, I'd suggest we should not base this issue on that change, but handle them separately and merge things, once they are ready. Otherwise the chain will grow and the patches here have to depend on the ongoing other thread.

I'll prepare a MR that isn't depending on the other issue to make things easier. At least as long as there's no maintainer feedback and speedup in the issues.

Anybody → closed merge request !12

@Grevil could you please have a look, now, as you're deep into this area?
So we can probably finish this!

Okay the implementation here conflicts with the other issue, I think. We should choose one of the approaches, but first discuss what's best and expected.

Depending on the implementation, we settle on in ✨ Allow Admin-users set username while user creation Needs work , we should either implement it or close this issue. If we settle on the prefixed username generation (e.g. email_registration_awnFqFb6af) updating the username doesn't make any sense.

@Grevil: Isn't this fixed in 2.x? Or at least implemented like it just makes sense? ;) So we might close this fixed or works as designed for 2.x?

This isn't fixed for the main module! We sync the mail address with the username in the submodule!

This might still be relevant for the main module, as when we change our mail address from "abc@test.com" to "123@test.com", we might also want, that the username changes from abc to 123, but this should definitely have its own setting.

I would set this to minor for now, as the submodule implementation will cover 99% of all cases.

Needs reroll, tests and discussion for the right solution, eventually moving up the logics from the submodule.
Feel free to proceed here. Happy to review MR.

The implementation has changed. If still relevant, it should be rethought and simplified. If no more relevant, we should close this won't fix. I guess it's an edge-case.