Migrate permissions to og_user_roles, instead of our own code

Verifying context settings turned out that deployment of this is blocked by og_user_roles having no support for extended contexts. See #613530: Not respecting extended group context for discussion and suggested patch.

Also attached updated patch which implements og_user_roles setting as well.

Ok, now that we have #613530: Not respecting extended group context committed, I've tested our code with that. Looks like we have a bug on our own in that we cache user permissions and then do not get notified of user_access() cache clearing. Since there is no such notification available, we should really just rely on user_access() instead of trying to implement a caching layer on top of that. So I worked to remove our caching layer (custom internal permissions system), and rely on user_access instead. This makes the og_user_roles integration work nicely.

I've run the test system with this, and it all passed (although it does not have too granular testing for permissions, it does check for some permission things).

I've added a @todo though for the remote submitter, since in that case, the OG context is not set, and OGUR will not kick in to grant the required permissions, so that will not work yet. I need to revisit that before this is viable, so the remote submission code works as nicely as the others.

Reviews are welcome as always!

Here is an update which hopefully resolves the remaining @todo. I've abstracted group setting in l10n_groups and added code to invoke that from l10n_remote to set a group context properly even in XML-RPC calls. That allows us to use the same permission models/mechanisms in that case too.

Now onto upgrade path testing and testing that this latest fix is right.

In testing, the update turned out to have a bug in removing existing permissions. Also, I've removed code and schema around the 'model' column in l10n_groups, since we do not use that for anything (og_user_roles handles all permissions) and added code to set the l10n_groups weight to before og_user_roles.

Doing more testing.

Ok, here is a well tested patch which also adds a user role for community managers (those who can hand out all these fine permissions). Existing group admins will get that role as well.

Also found and fixed a bug with l10n_remote module not accepting remote submissions properly.

I think this is as far as we can get here. Unfortunately og_user_roles will only grant one role per "workflow action", and the given role is not configurable on a per-group basis. Eg. some groups would want to grant all self-moderation, community moderation and community manager roles to all group admins for example, some groups will be more restrictive. I believe there should be a generic solution outside of l10n_server for this, it is not the job of our module to do this automation, since it is quite generic. In the interest of pushing this out as early as possible, I'll not postpone this issue on that automation but will get group maintainers to do the manual work of assigning roles when they need to do that.

I think this is good enough to be committed, but do not have the time now to do the full deployment, so just posting here and plan to come back to here soon to commit and do the deployment on localize.drupal.org.

BTW patch passes the existing automated tests (which admittedly do not cover lots of the permissions subtleties). It was also human-tested in various scenarios including remote string submission, users who are group admins but otherwise not admins and group members across different groups. I think this is as much as I could test this change, and I'm hopefully it will be fine deployed :)

@hass: there is code to do that, look at db_drop_field($ret, 'l10n_groups_group', 'model');

Committed and deployed on Drupal.org!

Ha, I was jumping to review and possibly advance #652460: Add permission to allow declining own translations but then realized that this change actually does not hand out group roles to people when the AJAX suggestion handling is done, so approval and decline actions via those AJAX callbacks was not possible. Also noted an issue with the string listing copy buttons in the output, which I'm also fixing here. Committing and deploying.

And updates to the tests. Now tests pass again.

News post of localize.drupal.org deployment at http://localize.drupal.org/node/616