Implement Job Router discovery endpoint for runners

What does this MR do and why?

This change set implements a new REST API endpoints that runners can use to discovery Job Router information.

The new endpoint requires authentication via the runner token in the Runner-Token header.

If the Job Router (KAS) is not available / enabled the endpoint returns with a 501 Not Implemented and an appropriate error message.

If it is enabled, discovery information is returned. Right now, that's just the Job Router (KAS) server endpoint.

Alternatives considered, but rejected:

• re-using the /api/v4/metadata / /api/v4/version endpoint.
  • Rejection reason: it requires authentication that we can't easily remove and we don't want to allow runner token authentication there to avoid coupling runner / job router concerns into that very generic endpoint.
• using a generic discovery endpoint (maybe something like .well-known/service-discovery.
  • Rejection reason: kinda duplicates to what we have with the aforementioned metadata and version endpoint. That endpoint is "not owned" (see feature category), which is not ideal. This endpoint would just be like that and authentication wouldn't be clarified either.

The current approach is the most boring solution at the moment and unblocks the Job Router efforts effectively.

Refs #582139 (closed)

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.