Allow wiki edits from non-members in project wikis

Problem to solve

Currently a GitLab users needs Maintainer or higher status to write in the wiki. This is completely against what wiki stands for, it's guiding principle and philosophy being that everyone can contribute.

Since you cannot give everyone Maintainer status, another solution is needed.

Proposal

Original proposal from @chrizilla

I have 2 solutions to propose, which I feel should both be implemented:

💡 ~"feature proposal" Add a project setting with a radio box:
allow all GitLab users (GUEST status) to edit the wiki: (*) yes ( ) no

💡 ~"feature proposal" Add a new status above GUEST but below REPORTER, named WIKI which receives all guest permissions plus wiki edit permissions.

If both proposals are implemented, a project owner can decide whether he wants to

• allow wiki contributions from everyone
• or give wiki access only to selected GitLab users without having to make them maintainers just for that.

Split the current dropdown in the project settings into two:

• One for read permissions, which keeps the current value of wiki_access_level.
  • We might want to rename the wiki_access_level column to read_wiki_access_level, if that doesn't conflict with the existing code.
• One for write permissions, which defaults to "Developers and above".
  • This will need a new column in the project_features table, which could be called write_wiki_access_level.
• Each dropdown shows all roles (including "Owners"), in addition to "Everyone With Access".
  • The role for write permissions must be >= the role for read permissions. This needs to be enforced both in the backend (through validations) and the frontend (through dynamically disabling the options which don't make sense).
  • See the wireframes below on how this should look.

In this issue we'll focus on project wikis only, though we'll definitely want to bring this to group wikis too once we're implementing group wiki settings in #208412 (closed).

Documentation

Update the docs in:

• https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions
• https://docs.gitlab.com/ee/user/permissions.html#wiki-and-issues
  • Split into two sections, since Wikis now will work differently than Issues.
  • Link/mention this section in https://docs.gitlab.com/ee/user/project/wiki/.

Testing

• New unit tests for policy changes
• New unit tests for project settings changes
• New front-end tests for new interface elements
• New feature tests

Security

This involves changing access rules; security review is recommended.