Fail deployment when configuration for blocked api endpoints is invalid to avoid security issues

The configuration for blocked API endpoint basically allows any value.
In case of typos or misconfiguration (like a /api prefix due to copy+paste from Apache/NGINX rules), the rules are essentially rendered useless.

We must check during deployment if the setting is making any sense to us.

1. Make sure there's no /, or /api or /api/v\d+/ at the beginning of each
2. Make sure the list is actually a list (so no invalid characters like ; or , etc)
3. Ideally check if the referred resource actually exists. (This might be hard to do!)

Also, the whole class of API filtering should be refactored:

1. Extract the matching logic and have unit/integration/API tests
2. Look into using UriInfo instead of or in addition to ResourceInfo to make the code potentially less complex
3. Remove Jetty StringUtil (also add a check in Maven to flag or fail PRs introducing these imports!)
4. Potentially make the class more restrictive in it's choices what are acceptable configuration combinations

In addition: the setup scripts are still applying database options for the blocking configuration. This should be cleaned up.

Start by locating the blocked API endpoint configuration, its deployment validation, and the setup scripts that apply database options. Review the API filtering entry points and existing test coverage, then define completion as rejecting malformed configuration during deployment, covering matching behavior with tests, and cleaning the setup options.