Request access for a certificate

**As a** NLX user
<br>**I want** to select the certificate for which I want to request access
<br>**so** that specific certificate is included in the access request.

### How to handle the UI part of it 
1. directory
- the quick action button is removed
- the status column only contains errors/warnings of one of underlaying the access requests 

![directory](/uploads/12aea0bd1072b0ea5a2a2c153a6869d3/directory.png)

1. Service detailpage

![Group_52](/uploads/23bf7d0d6de5b354ce08ae6d40176704/Group_52.png)

1. Access request confirmation modal

![accessrequest-modal](/uploads/82590125f2bd3995ea5ef42ba68e45b7/accessrequest-modal.png)


**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. If a organization does not have an outway, when opening the service detail view we should display a message something like "Please configure a outway to request access"

TODO:

1. [x] Include certificate in RequestAccess call
1. [x] Include certificate in GetAccessRequestState call
1. [x] Include certificate in GetAccessProof call
1. [x] Include certificate fingerprint in ListAccessGrantsForService call
1. [x] Include certificate fingerprint in ListIncomingAccessRequests call
1. [x] Include certificate fingerprint in ListOutgoingAccessRequests call
1. [x] For an access proof retrieve outways attached to a certificate
1. [x] Add certificate fingerprint to the outway database table
1. [x] Remove stacktrace from front-end
1. [x] The get service detail call should include a array of access requests and access grants instead of a single object
1. [x] Add access per certificate to orders on the back-end
1. [x] Update plantuml if necessary
1. [x] implement UI for listing outways with / without access
1. [x] implement UI for confirming requesting access
1. [x] display error message on directory if one of the access requests failed to send
1. [x] enable selecting outway / public key fingerprint with service when adding an order
1. [x] claim per service
1. [x] restrict selecting only a single Outway per service when creating an order (FE & API)
1. [ ] When in a eco system of old, pre-this-change versions, the eco system should continue to work
1. [x] Add extra Outway & certificate to dev, review and acc environment, so we can test this functionality

TODOs after merging the MR:

1. [ ] Update sequence diagrams for ordeders, see epic: &27+


**Test scenario for backwards compatibility**

> bestaande verbinding -> ene partij doet upgrade -> verbinding zou moeten blijven werken

```
      // 1.
      // review cluster weggooien
      // alle deployments deployem voor 0.124
      // access request maken & goedkeuren voor een service (gemeente stijns moet toegang hebben tot rvrd)
      // order toevoegen en testen met curl (toegang tot rvrd delegeren naar vergunningsoftware)
      // handmatig via k9s de directory updaten naar de review tag (2d6b6fb9) [van registry.nlx.reviews/commonground/nlx/nlx/nlxio/management-api:2d6b6fb9]
      // controleren of we met het toegangsverzoek nog steeds toegang hegbben
      // handmatig via k9s de rvrd updaten naar de review tag (2d6b6fb9) [van registry.nlx.reviews/commonground/nlx/nlx/nlxio/management-api:2d6b6fb9]
      // toegang rechtstreeks & via order testen
      // -> rechtstreekse toegang werkt. toegang via order faalt, de outway laat weten: 'nlx-inway: no access'. vermoedelijk omdat de structuur van de claim is aangepast.

      // 2.
      // review cluster weggooien
      // alle deployments deployem voor 0.124
      // access request maken & goedkeuren voor een service (gemeente stijns moet toegang hebben tot rvrd)
      // order toevoegen en testen met curl (toegang tot rvrd delegeren naar vergunningsoftware)
      // handmatig via k9s de directory updaten naar de review tag (2d6b6fb9) [van registry.nlx.reviews/commonground/nlx/nlx/nlxio/management-api:2d6b6fb9]
      // controleren of we met het toegangsverzoek nog steeds toegang hegbben
      // handmatig via k9s de gemeente stijns updaten naar de review tag (2d6b6fb9) [van registry.nlx.reviews/commonground/nlx/nlx/nlxio/management-api:2d6b6fb9]
      // toegang rechtstreeks & via order testen
```




** Questions **

1. Can we keep the history of access requests/grants in the auditlog? 
1. This will either be  breaking change or we need to add if/else to most calls concerning access request/grants. If we decide to make this a breaking change it will only affect setups were the consumer and provider use a different version of NLX. This has been discussed during our review. Conduction was the only stakeholder with active NLX installations. Their response: Mag een breaking change zijn, dan is het duidelijk voor iedereen.
Alleen last van voor demodam,  maar dat cluster ligt er momenteel uit, dus momenteel geen last van. Als het weer up gaat, dan zal Robert updates moeten doorvoeren.

1. Should requests between NLX components contain the version of the component? This information could be used to give our users more specific error messages.
 

**:link: Reference links**

Story points: 21.0