fix(aggregator): properly handle `404` errors in http server

Content

This PR fix the handling of 404 errors in the aggregator http server.

In case of a 404 the custom rejection middleware immediatly emit a rejection (this custom rejection was added to set the appropriate status code for API Version Mistmatch errors). This means that no other middleware would be applied nor our custom headers.

Pre-submit checklist

Branch
- [x] Tests are provided (if possible)
- [x] Crates versions are updated (if relevant)
- [ ] CHANGELOG file is updated (if relevant)
- [x] Commit sequence broadly makes sense
- [x] Key commits have useful messages
PR
- [x] No clippy warnings in the CI
- [x] Self-reviewed the diff
- [x] Useful pull request description
- [x] Reviewer requested

Comments

This problem cascade to the browser javascript fetch api, the missing headers make the api immediately throw an error thus making impossible to handle the 404 in a idiomatic way.

In this example the status code can't be checked in the then block since a exception is raised (note: the exception doesn't contains the status code).

fetch(aggregatorEndpoint)
  .then((response) => {
    if (response.status === 404) {
      // do something with it
    } else {
      return response.status === 200 ? response.json() : {};
    }
  })
  .catch((error) => {
    console.error("Fetch status error:", error);
  });

This problems made more cumbersome the fallback to Epoch Setting mechanism used in PR #2128, we had to handle it in the catch block without the ability to check that it was indeed a 404 or not.

input-output-hk / mithril