### Description

The [Get API key information API](https://www.elastic.co/guide/en/elasticsearch/reference/master/security-api-get-api-key.html) can currently filter the returned keys by:
 * key id/name
 * keys owned by the calling user
 * keys owned by other users, by `realm_name` and `username`

Irrespective of the filtering used, both invalidated and expired (but not yet deleted) keys will be included in the response.
In the response, keys have the `invalidated` boolean property, as well as the `expiration` property that contains the UNIX timestamp past of which the key is no longer valid for authentication.

I propose we introduce a way for the API to support retrieving:
* only valid API keys (not return invalidated keys) - using a boolean request parameter
* keys not expired before a certain timestamp - using a timestamp parameter that defaults to "now" - also note that keys' experiation date is always checked against the local node's clock
server/src/main/java/org/elasticsearch/TransportVersion.java
* To add a new transport version, add a new constant at the bottom of the list that is one greater than the current highest version, ensure
 * it has a unique id, and update the {@link CurrentHolder#CURRENT} constant to point to the new version.
 * <h2>Reverting a transport version</h2>
 * If you revert a commit with a transport version change, you <em>must</em> ensure there is a <em>new</em> transport version representing
 * the reverted change. <em>Do not</em> let the transport version go backwards, it must <em>always</em> be incremented.
 * <h2>Scope of usefulness of {@link TransportVersion}</h2>
 * {@link TransportVersion} is a property of the transport connection between a pair of nodes, and should not be used as an indication of
 * the version of any single node. The {@link TransportVersion} of a connection is negotiated between the nodes via some logic that is not
 * totally trivial, and may change in future. Any other places that might make decisions based on this version effectively have to reproduce
 * this negotiation logic, which would be fragile. If you need to make decisions based on the version of a single node, do so using a
 * different version value. If you need to know whether the cluster as a whole speaks a new enough {@link TransportVersion} to understand a
 * newly-added feature, use {@link org.elasticsearch.cluster.ClusterState#getMinTransportVersion}.
 */
public record TransportVersion(int id) implements VersionId<TransportVersion> {
    /*
     * NOTE: IntelliJ lies!
     * This map is used during class construction, referenced by the registerTransportVersion method.
     * When all the transport version constants have been registered, the map is cleared & never touched again.
     */
    private static Map<String, Integer> IDS = new HashMap<>();
    private static TransportVersion registerTransportVersion(int id, String uniqueId) {
        if (IDS == null) throw new IllegalStateException("The IDS map needs to be present to call this method");
        Strings.requireNonEmpty(uniqueId, "Each TransportVersion needs a unique string id");
        Integer existing = IDS.put(uniqueId, id);
        if (existing != null) {
            throw new IllegalArgumentException("Versions " + id + " and " + existing + " have the same unique id");
        }
        return new TransportVersion(id);
    }
    public static final TransportVersion ZERO = registerTransportVersion(0, "00000000-0000-0000-0000-000000000000");