The IsVerified and IsVerifiedOrReadOnly permission classes might bypass some checks

I got stuck at two failing tests in !1070 (merged) because the IsVerified permission class behaves like the IsVerifiedOrReadOnly permission class; it allows access to authenticated users for GET, HEAD and OPTIONS.

This is probably due to the construction of this class using a bunch of mixins that could be overriding each other. It is possible that IsVerifiedOrReadOnly is affected by a similar issue and user scopes are not properly checked.

I think of three reasons why we never noticed this issue before:

• It's a feature, not a bug (we actually wanted IsVerifiedOrReadOnly on an endpoint)
• We rarely test as logged out users
• We do not always add unit tests for test_xxx_requires_login and test_xxx_requires_verified
• There are no separate, isolated unit tests for the permission classes, even though they are perfectly doable.

Affected endpoints

TL;DR: You do not need to verify your email address or have the proper user scopes to fill our S3 bucket with terabytes of stuff.

• RetrieveTranscription
• RetrieveMetaData
• ListRepositories
• RetrieveRepository
• RetrieveExternalRepository - note that this should be a list and not a retrieve endpoint, OpenAPI bug
• RetrieveRevision
• ListWorkers
• ListWorkerVersions
• RetrieveWorkerVersion
• ListDataImports
• RetrieveDataImport
• ListDataFiles
• RetrieveDataFile
• ListWorkerRuns
• RetrieveWorkerRun
• ListProcessElements
• RetrieveImage
• ListOAuthProviders
• StartOAuthSignIn
• ListCredentials
• RetrieveCredentials
• RetryOAuthCredentials
• CreateImage
• CreateIIIFURL
• CreateIIIFInformation
• From !1070 (merged): ListJobs, RetrieveJob

This almost does not affect POST/PUT/PATCH/DELETE and corpus restrictions still apply, so the real impact is pretty low.

• Someone is able to register with an invalid email, then:
  • Retrieve any image knowing its UUID
  • Retrieve the OAuth providers (so just "GitLab.com")
  • Fully authenticate with any GitLab account without being able to add a repo to Arkindex
  • List our workers and worker versions and GitLab commit URLs without being able to use them
  • Create any image from an external IIIF server (that we have "whitelisted" in the ImageServer admin)
  • Create images in S3 and start uploading, but never perform checks; this still means you can fill our S3 bucket with terabytes of anything you want.
• Internal users (workers) that do not have the verified email checkbox checked in the admin can run into issues when creating things related to the above endpoints due to the mixin short-circuiting the internal check.
• The bug in IsVerifiedOrReadOnly affects other important endpoints (ListCorpus, RetrieveCorpus, ListElements, ListElementParents, ListElementChildren, ListCorpusMLClasses), but those do not use UserScopes, so it doesn't actually matter.