Do not show locked banner if backend sends restrictions.allowUpdate=false

[MichaelBuessemeyer]

Context

When an annotation with othersMayEdit turned on is shared publically and another user from a different organization opens the annotation a locked banner is shown. This might be confusing as the annotation is not locked but the user is not allowed to edit this annotation due to being from another organization (see #7923).

Expected Behavior

No logged banner should be rendered.

Current Behavior

A logged banner is rendered. See #7923 (comment).

Steps to Reproduce the bug

• Cannot reproduce the bug anymore / needs deeper investigation.

• Same as Forbid editing other orga’s public annotations #7923 (comment)

Your Environment for bug

• Browser name and version: e.g. Chrome 39
• Operating System and version: e.g. Windows 10
• Version of WEBKNOSSOS (Release or Commit):
• Specific to long-running jobs (set jobsEnabled=true in application.conf)
• Specific to webknossos.org (set isDemoInstance=true in application.conf)

[MichaelBuessemeyer]

The reason why this banner is shown is because the forntend has an overloaded usage of the tracing.restictions.allowUpdate field. The field should save whether the user has the permissions to update an annotation.
In case othersMayEdit is turned on, one additionally has to acquire the annotations mutex to be able to edit this annotation.

The problem here is that the frontend sets tracing.restrictions.allowUpdate to false while it is trying to acquire the mutex. This lets the frontend "forget" that it was originally allowed to edit the annotation.
=> Thus, the usage of tracing.restrictions.allowUpdate is overloaded as it saves whether a mutex is being fetched and whether a user is allowed to update the annotation (eventually with the mutex).

Therefore, I suggest introducing a new frontend only field that saves whether the frontend is currently fetching the annotations mutex. E.g. state.tracing.isTryingToAquireMutex
Then everywhere where tracing.restictions.allowUpdate was checked to avoid updates of the annotation, a new accessor method could be used: e.g.

function allowUpdateAndMaybeHasMutex(state){
 return state.tracing.restictions.allowUpdate && !state.tracing.isTryingToAquireMutex;
}

[MichaelBuessemeyer]

While implementing the suggested fix in PR #8270 we discussed that the whole restrictions should be reworked so that the frontend doesn't manipulate the data received from the backend anymore to suit it better. Instead a standalone refactoring pr of this should be done.

#8273 now only implements a quick fix.

E.g. writing accessors for each permission case in which the annotation.restrictions are simply passed and the accessors return a boolean value. Naming would be very important here to avoid confusion.