FeatureFlagUtils is a JS library used in the test runner to check if feature flags are present and/or enabled.

The README recommends using this library for querying the setting for a feature flag, and using it to skip tests in multiversion environments.

The way the library works is by taking a connection to the cluster as input. If the connection is to a mongod node, it uses it directly; otherwise, it makes a new connection to an arbitrary mongod in the cluster. Then it does the following algorithm using that connection:

1. Use getParameter to get the FCV of the node
2. Use getParameter again to get the featureFlag information
3. Compare the minVersion for the featureFlag retrieved from the server to the FCV retrieved from the server to see if the feature flag could be enabled on the version
4. If the feature flag can be enabled on the version, and the server says it is enabled, and the user of the library didn't pass the 'ignoreFCV' option, conclude that the feature flag is enabled.
5. Otherwise, conclude that it is not-present if we didn't see it in our getParameter output, or conclude that it is present-but-disabled if we did.

There are a few scenarios where it is unclear what it means for a 'feature flag to be enabled' on the cluster, mostly around multiversion testing, where the correctness of this algorithm is questionable:

1. If the feature flag exists on mongos, and we are in a suite where we use last-LTS mongos but current version shards, the library will always report the status of the feature flags on the shards, even if it is missing on mongos
2. On a mixed-version cluster, the value returned by isEnabled and isPresentAndEnabled depends on the connection passed to the library - you will get different answers if you ask different version nodes as to whether the feature flag exists. This isn't obvious from the API and is especially dangerous in passthrough tests where we may talk more to secondaries, etc, depending on the suite configuration.

It also contains the "isPresentAndEnabled" helper, which it notes is easy to misuse because of the fact that it can silently prevent tests from running. This can occur not only after a feature flag is removed, as the test notes, but whenever the connection that happened to be passed to the library was to an older-version node.

It would be nice if we could

1. Write down the possible states of a feature flag in a cluster, including multiversion
2. Get rid of isPresentAndEnabled checks (WE have seen some cases where tests are accidentally not running after the feature flag is enabled, like SERVER-73509).
3. Provide a simple command in mongos/mongod that can be used to determine the cluster's current state, so the passed in "db" to this library doesn't need to be adjusted carefully as it is today