Do not allow to trigger Duo Code Review if user doesn't have access

Background

It was reported in #493890 (comment 2164882679) that user can trigger Duo Code Review (via /duo_code_review quick action) even if they're not allowed to do not having Duo enterprise access.

Proposed fix

1. Introduce a policy following: https://docs.gitlab.com/ee/development/cloud_connector/#permission-checks.
2. Call that policy check in https://gitlab.com/gitlab-org/gitlab/-/blob/5cf2cfec789d561e3d75fff9cd0ca07de658e1a0/ee/app/models/ee/merge_request.rb#L557-565.

added gitlab-org#14825 (closed) as parent epic

changed the description

added backend bugfunctional devopscreate groupcode review typebug labels

set weight to 2

added sectiondev label

changed the description

@francoisrose @phikai just a FYI, added this to 17.7 for planning purposes and included it in the Experiment epic.

/cc @dskim_gitlab

Makes sense - thank you!

changed milestone to %17.7

mentioned in issue #493890 (closed)

Does !171102 (merged) cover this already?

Moving from backend to frontend for capacity purposes.

No I don't think it does

But with that change we need to not allow the bot to be assigned as a reviewer and if the bot is assigned then we need to not allow the re-request button to be clicked

added frontend label and removed backend label

added Deliverable label

assigned to @iamphill

Setting health status to on track as the milestone has just begun.

Issue participants are welcome to override this by setting the health status to another value.

changed health status to on track

added twtriaged label

added workflowin dev label

mentioned in commit 225c683a

mentioned in merge request !173734 (merged)

mentioned in commit fcca302b

mentioned in commit 24ed1adc

mentioned in commit fb5cf793

mentioned in commit a1003f55

added workflowin review label and removed workflowin dev label

mentioned in commit 87d6f24b

mentioned in commit 4971f7f6

mentioned in commit 2c87b0f0

mentioned in commit c9fa17f5

closed

mentioned in issue gitlab-org/quality/triage-reports#21263

mentioned in issue #517386