fix(api): fix media route timeout

[kishore03109]

Problem

We had an issue where a request such as "media/images%20blah/pages" timeing out, see incident here. while we do have an overall catch all in our main router, there are quite a number of calls in our subrouter that fails.

Solution

for the media subrouter, this should return a 404. this is not applied across all the routes as some of the routes depend on the fall through behaviour to function. therefore, this pr is only scoped to return only for the media subrouter

Other solutions that did not work

1. adding a next() to every subrouter
2. adding an error handler to every subrouter such that if subrouter captures a group and does not handle it, an error should be thrown. unfortunately, this caused quite a number of functionality to break, rather this hotfix go in first while and revisit this when we get timeouts again

Breaking Changes

• Yes - this PR contains breaking changes
  • Details ...
• No - this PR is backwards compatible with ALL of the following feature flags in this doc

Tests

• Get call an authenticated request (ie you have assess to the site with the relevant valid cookie) to the backend

GET http://localhost:8081/v2/sites/kishore-test-dev-gh/media/images%2Fblah.png/pages

• Assert that you receive a res not found error rather than a timeout

[seaerchin]

why not put this as the terminating middleware in our server.js? this would allow us to catch all missing routes and to return a sensible response

[kishore03109]

a terminating middleware already exists at server.js where our overall error handler resides.

the problem exists when a subrouter captures a group and does not handle it, causing a timeout.
do note that some of our routes fall through while others dont, so i couldnt append this at the end of all subrouters because that broke quite a number of functionality within the cms, and the manual test space for such a pr will be unreasonably large. stance here will be to monitor for 5xx errors and then fix them

[seaerchin]

actually that's weird because i always thought if the subrouter doesn't capture the route, it should fall over to the next one.

ie, if subrouter A captures /about/a and i get a request with /about/b, it should fall to the next router in the stack.

this isn't very important given that we assume most users are calling from the frontend but it is weird tho