feat(cat-voices): cip36 registrations consolidated endpoint

[cong-or]

Consolidated endpoint for cip36 registrations.

Example usage:

Single registration with lookup param as vote key:

Single registration bound by time of Unix timestamp:
http://localhost:3030/api/draft/cardano/registration/cip36?lookup=0xa31e0e52dfc72b6bc142c60dd119d46dafe660db7cc3240968c9878497ce9e8e&asat=TIME:1736164751

Single registration bound by time of slot#:
http://localhost:3030/api/draft/cardano/registration/cip36?lookup=0xa31e0e52dfc72b6bc142c60dd119d46dafe660db7cc3240968c9878497ce9e8e&asat=SLOT:11718738

When not bound by time, return latest registration for given vote key.

http://localhost:3030/api/draft/cardano/registration/cip36?lookup=0xa31e0e52dfc72b6bc142c60dd119d46dafe660db7cc3240968c9878497ce9e8e

The same mechanics apply for stake address lookup

http://localhost:3030/api/draft/cardano/registration/cip36?lookup=stake1u9ugz54klca9xqe7nhmdpp23dsp95gkw8snk94gl2rwpdpqcvyze0

.......

ALL registrations: Snapshot

Endpoint requires X-API-Key header with secret token defined in ENV VAR. Contact SRE.

http://localhost:3030/api/draft/cardano/registration/cip36?lookup=ALL

ALL registrations bound by time of slot#:

http://localhost:3030/api/draft/cardano/registration/cip36?lookup=ALL&asat=SLOT:12313103

ALL registrations bound by time of Unix timestamp

http://localhost:3030/api/draft/cardano/registration/cip36?lookup=ALL&asat=TIME:1736164751

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 385/385}$ | ${\color{red}Fail: 0/385}$ |

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 389/389}$ | ${\color{red}Fail: 0/389}$ |

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 389/389}$ | ${\color{red}Fail: 0/389}$ |

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 389/389}$ | ${\color{red}Fail: 0/389}$ |

[Mr-Leshiy]

The general issue in this PR is the response types for error cases.
It used only an UnprocessableContent response type for every error case which is not correct.

• UnprocessableContent should not be returned by us explicitly in most of the cases, it will return during the request arguments parsing/processing.
• For any database database failure we should call handle_error where in most cases it will just return a 503 response or in some special cases return service_unavailable
• If something fails because of the incorrect request argument, but it is related to the business logic of the endpoint (e.g. you are getting a stake address which is structurally correct, but during endpoint execution something fails because of it) then it should be BadRequest response, and such response must be specified inside the response enum for such endpoint.

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 388/388}$ | ${\color{red}Fail: 0/388}$ |

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 388/388}$ | ${\color{red}Fail: 0/388}$ |

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 388/388}$ | ${\color{red}Fail: 0/388}$ |

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 390/390}$ | ${\color{red}Fail: 0/390}$ |

[Mr-Leshiy]

LGTM

[github-actions]

✅ Test Report | ${\color{lightgreen}Pass: 386/386}$ | ${\color{red}Fail: 0/386}$ |