[18.0][FIX] base_user_role: don't let roles impose self-writable groups

[imanie383]

A role implying one of the groups the module itself declares as the user's own
forces that group back on its members, and there is no way to opt out.

_get_self_writable_groups() is subtracted from the user's own groups in
set_groups_from_roles, so the synchronisation never takes those groups away.
But it is not subtracted from the groups contributed by the roles, so a role
implying one of them adds it again on every res.users.write().

This is plainly visible with mail.group_mail_notification_type_inbox, because
notification_type is a stored field computed from that group. For a user whose
role implies it, switching to Handle by Emails is impossible:

1. the inverse of notification_type removes the group;
2. set_groups_from_roles runs within the same write and adds it back;
3. the compute follows the group and returns the user to inbox.

Saving looks like it worked and the value is back to "Handle in Odoo" on the next
read. Removing the group by hand only lasts until that user's next write, or
until Update users is pressed on the role.

This was found on a production database where five roles implied that group and
twelve users were stuck on inbox notifications.

What this PR changes

The self-writable groups are subtracted from the roles' groups as well, so a role
neither grants nor removes them and the choice stays with the user.

After the fix, base_user_role behaves like core does for any other group that
implies a self-writable one: core's UsersImplied.write may still re-add the
group through the role's own group, but it does not re-trigger the compute, so
the user's stored preference is preserved. The point of the fix is precisely to
stop the module from issuing the explicit groups_id write that did re-trigger
it.

Tests

test_notification_type_not_forced covers it: a role implying the inbox group,
a user who picks inbox, then email, and an unrelated write afterwards to make
sure the synchronisation does not hand the preference back.

Verified on a clean 18.0 database (core + enterprise, base_user_role freshly
installed): the new test fails on 18.0 with 'inbox' != 'email' and the whole
suite passes with the fix, 20 tests, no errors. The existing
test_notification_type_not_reset and test_notification_type_reset still pass,
so the group is still never taken away from the user, and a user demoted to a
share one is still moved to email.

[OCA-git-bot]

Hi @sebalix, @novawish, @jcdrubay,
some modules you are maintaining are being modified, check this out!