"Administer Users" permission should be separate from "Administer Account Settings"

Thanks @genellann, but there is no need to reupload patches just because the filename is not according to the conventions.

---------

Thanks everyone for working on the D7 patch! I tried to go through the whole issue and relevant comments, but I am sorry if I have missed something.

There is one scenario, where two concrete steps worries me and that is (see steps 3 and 5):

1. Install clean D7, create a separate non-admin user and a role with administer users permission
2. Assign the role with the permission to the newly created non-admin user - the user now can access both admin/config/people/accounts and admin/people (this is OK)
3. Enable the Separate administer account settings permission checkbox - the user suddenly cannot access admin/config/people/accounts. What was the reason to remove the update hook? I think if we want to be 100% safe, we should grant the new permission to all roles which have administer users once that checkbox is enabled
4. Grant the new administer account settings permission to the role - user now can access admin/config/people/accounts again

(this is OK)

5. And then disable the checkbox Separate administer account settings permission

The step 5 is the most problematic I think. Because when you uncheck that checkbox, the permission is still granted to the role, despite the fact that it is not displayed on admin/people/permissions anymore. I am not a great fan of such leftovers in database, as these can cause subsequent issues. For example, after the admin uncheck that checkbox, this

user_access('administer account settings', $non_admin_account)

will still return TRUE, even the permission does not exists anymore. This can cause issues in custom code/contrib modules, etc.

Just to summarize, I think the most safe approach will be to grant the permission to all roles having administer users once enabled (not entirely sure why this was removed) and once disabled, we need to remove the permission from all roles. We should also update the tests to check this process.

Also found a minor nitpick (see the extra whitespace):

+    $GLOBALS['conf'] ['user_enable_separate_account_settings'] = $form_state['values']['user_enable_separate_account_settings'];

---------

According to the backport policy, this D7 part should be split to the separate issue. I am not going to do it yet, because the patch seems to be mostly ready. Let's see if there will be any response/activity after my review and we will see what next. In case we will need more discussion or patch iterations to update it, we can split it to not cause additional noise here. Thanks!

Just to clarify this a bit, when speaking about "What was the reason to remove the update hook?", I meant the process of granting the new permission to all users. I know that the update hook was not suitable after the patch was changed to opt-in, but the logic could be moved to the submit handler, not removed.