'expireAfterSeconds' can be persisted as type int, long, or decimal in the durable catalog. This can cause index metadata inconsistencies across multiversion clusters (SERVER-92364), among other issues. 

The existing approach to normalize 'expireAfterSeconds' to integer types is ineffective / incomplete for several reasons.
The InvalidTTLIndexFixer runs onStepUp(), and tries to normalize any non-int 'expireAfterSeconds' to their integral value via collMod. 
However

• collMod updates 'expireAfterSeconds' to be of type long when it updates the durable catalog (BSONCollectionCatalogEntry::IndexMetadata::updateTTLSetting(long long newExpireSeconds))
• The onStepUp() approach is per-replica set, and does not account for sharded environments or FCV.

• • Pre 7.3, createIndexes stored 'expireAfterSeconds' as the provided numeric type (double, long, int). 
  • Starting 7.3, createIndexes silently truncates 'expireAfterSeconds' to an integral value.
• There is a bug that collMod is a no-op when the old and new expireAfterSeconds are equivalent when both are casted to type safeNumberLong() (SERVER-92366).

Whatever approach we choose, it should tackle 'expireAfterSeconds' type consistency across shards, replicas, and different server versions.

Old Description
InvalidTTLIndexFixer can find 'expireAfterSeconds' of type kNonInt when running on data generated from the newest version of mongod.

SERVER-77828 aimed to normalize expireAfterSeconds into an int on creation/collMod. The InvalidTTLIndexFixer runs on stepUp() to normalize any legacy data from older versions during upgrade.

We should investigate why it still finds kNonInt 'expireAfterSeconds' on non-legacy data.