Feature request: Improve status code / message response from User Consent APIs

[msbreton]

Describe the bug 🪲
Feature Request/Improvment

User consent APIs return a 400 (bad request) in multiple situations, making it hard to identity cause.

For example:

• When GET /api/v1/amt/userConsentCode/{guid} is called, we receive a 200 OK response, and the code pop’s up on the screen as expected.
  However, if we execute the same call again, it results in a 400 Bad Request response. Expecting to receive a 409 Conflict response instead.

• When the GET /api/v1/amt/userConsentCode/{guid} is called, we receive a 200 OK response, and the code pops up on the screen as expected.
  When we confirm the consent code with the payload, we receive a 200 OK response, and the code disappears as expected.
  However, if we execute the call again, it results in a 400 Bad Request response. We were expecting to see a code pop up on the screen again or that a different status code or message was returned.

• Similar results with DELETE/api/v1/amt/deactivate/{guid} as when User Consent hasn't been requested nor established, it returns 400 Bad Request.

To Reproduce 🪜
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
It would be helpful if a singular status code and or message was returned in each case so we would know exactly why the call failed.

Screenshots 🖼️
If applicable, add screenshots to help explain your problem.

AMT Device (please complete the following information): 🖥️

• OS: [e.g. Linux Kernel & Version]
• AMT Version: [e.g. 11.8.5, 12.0.45]
• AMT Configuration Mode: [e.g. Admin Control Mode or Client Control Mode]
• Network Configuration [e.g. Dynamic IP or Static IP]

Service Deployment (please complete the following information): ⛈️

• Deployment Type: [e.g. Azure, Docker, K8s]
• Node Version: [e.g. LTS 14]
• Component & Version: [e.g. RPS 2.0.0]

Additional context
Add any other context about the problem here.