[Enhancement]: invert Authentication.UserCreate RPC's UserCreateRequest.verify

[kon14]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the Issue Tracker for a feature request that matches the one I want to file, without success.

Suggestion

The Authentication.UserCreate RPC accepts a UserCreateRequest message type, which includes a bool field named verify.
The current behavior of this field is highly misleading in regards to how user creation and verification are handled.

At a glance, the field's name clearly suggests that setting it to true would immediately verify the user.
However, in practice, setting verify to true does not result in verification, but instead implies that the user must be verified later.

In contrast, setting it to false doesn't merely not enforce initiating the verification process, but actually verifies the user on the spot:

user = await models.User.getInstance().create({
          email,
          hashedPassword,
          isVerified: !verify,
        });

This behavior is not intuitive and can easily lead to mistakes in user management logic.

To improve clarity and align the behavior with user expectations, I'd consider introducing the following breaking changes during the next major version bump:

• rename the proto field to isVerified or verifyUser (so as to prevent implicitly breaking existing consumers)
• likewise, update the RPC wrapper method in grpc-sdk

[kkopanidis]

It can be confusing sure, but a rename would be something like "requireVerification" in order to match the current behaviour. isVerified isn't the whole picture since it will continue to hide the fact that if it is false and email would be sent

[kon14]

An email would only ever be sent if glogal cfg's verification is required, with email sends enabled.
That is not any singular RPC's specific behavior (if it is, it's most likely a bug).

If isVerified is true, it shouldn't initiate any verification flows no matter what, as it's assumed to be verified by somebody else.,
If it's not, it should stay in-line with the rest of the APIs, sending emails or not, depending on project/module cfgs.