Add support for the editor role

[nkaretnikov]

Fixes #675.

Description

This pull request:

• adds the alias editor for developer to role mappings, which is supported by the HTTP API and the DB
• adds tests
• updates documentation.

The auth flow is as follows:

• an HTTP API is called to set the role (can be either editor or developer)
• the role is written to the DB (always written as developer)
• when some page is accessed, the role is checked on auth by matching the DB value against role_mappings
  • developer from the DB is matched against editor or developer in role_mappings (in this order).

All user-visible parameters (the HTTP API and the role_mappings setting) allow for both editor and developer.
The name editor is preferred, which is reflected in the documentation.
The name developer is supported for compatibility reasons.

How I tested this locally:

• to make sure that role_mappings are actually used by the test, I commented out editor in the default role_mappings
  • the test errored out as expected
• to make sure that developer is still supported, I replaced editor with developer in the default role_mappings
  • the test succeeded as expected
• to make sure that permissions are checked, I replaced the permissions of editor in the default role_mappings
  • the test errored out as expected

After making each of these changes in the application, I ran

PYTEST_ADDOPTS="-rpfxs -k test_end_to_end_auth_flow" pytest tests

and looked at the test output.

Pull request checklist

• Did you test this change locally?
• Did you update the documentation (if required)?
• Did you add/update relevant tests for this change (if required)?

Additional information

[netlify]

✅ Deploy Preview for kaleidoscopic-dango-0cf31d canceled.

Name	Link
🔨 Latest commit	2284852
🔍 Latest deploy log	https://app.netlify.com/sites/kaleidoscopic-dango-0cf31d/deploys/65b584bee0269a0008f41490

[nkaretnikov]

Typo fix: "Lets" -> "Let's"

[dcmcand]

Just the one area that I think needs changed. Other than that, looks good.

[dcmcand]

An assert outside of a test strikes me as odd. Looking into it, it seems like some compilation flags remove assert statements. If this check is valuable, I think raising an exception here would be more valuable. However, I am not sure that this represents an unrecoverable error, since we would still know what to do with that data. We could just handle it and log an warning that data that shouldn't be in the db is. Or if it really does represent an unrecoverable error, than raising an exception seems better than an assert.

[nkaretnikov]

@dcmcand Changed to raise. It's not unrecoverable, but it's a mistake that's easy to make when potentially refactoring or adding new DB APIs.

For example, see the change in conda-store-server/conda_store_server/api.py in this PR. The old code would bypass validate_role because .update is a lowel-level API, which just skips ORM validation logic. That was caught by the tests, which is how I noticed. But we might not have good coverage for some new yet to be added APIs, so I want to make sure this is never a problem.

[nkaretnikov]

@dcmcand PTAL. Note: I want to keep the diff minimal to make it easier to review, I'll rebase after this is approved.

[dcmcand]

🚀