### 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
import java.util.Map;
import java.util.NavigableMap;
import java.util.Set;
import java.util.TreeMap;
/**
 * Represents the version of the wire protocol used to communicate between a pair of ES nodes.
 * <p>
 * Prior to 8.8.0, the release {@link Version} was used everywhere. This class separates the wire protocol version from the release version.
 * <p>
 * Each transport version constant has an id number, which for versions prior to 8.9.0 is the same as the release version for backwards
 * compatibility. In 8.9.0 this is changed to an incrementing number, disconnected from the release version.
 * <p>
 * Each version constant has a unique id string. This is not actually used in the binary protocol, but is there to ensure each protocol
 * version is only added to the source file once. This string needs to be unique (normally a UUID, but can be any other unique nonempty
 * string). If two concurrent PRs add the same transport version, the different unique ids cause a git conflict, ensuring that the second PR
 * to be merged must be updated with the next free version first. Without the unique id string, git will happily merge the two versions
 * together, resulting in the same transport version being used across multiple commits, causing problems when you try to upgrade between
 * those two merged commits.
 * <h2>Version compatibility</h2>
 * The earliest compatible version is hardcoded in the {@link #MINIMUM_COMPATIBLE} field. Previously, this was dynamically calculated from
 * the major/minor versions of {@link Version}, but {@code TransportVersion} does not have separate major/minor version numbers. So the
 * minimum compatible version is hard-coded as the transport version used by the highest minor release of the previous major version. {@link
 * #MINIMUM_COMPATIBLE} should be updated appropriately whenever a major release happens.
 * <p>
 * The earliest CCS compatible version is hardcoded at {@link #MINIMUM_CCS_VERSION}, as the transport version used by the previous minor
 * release. This should be updated appropriately whenever a minor release happens.
 * <h2>Adding a new version</h2>
 * A new transport version should be added <em>every time</em> a change is made to the serialization protocol of one or more classes. Each
 * transport version should only be used in a single merged commit (apart from BwC versions copied from {@link Version}).
 * <p>