* fix KeyRangeRef::isCovered()

* reproduce bug

* more unit test added

* fmt

… failed

In FastTriggeredWatchesWorkload, if the randomized new value for the given
`setKey` happens to be the same as the current value, the following will hold

- `first` is true, and
- `getDuration` is 0, and
- assertion `lastReadVersion - ver >= SERVER_KNOBS->MAX_VERSIONS_IN_FLIGHT || lastReadVersion - ver < SERVER_KNOBS->VERSIONS_PER_SECOND * (25 + getDuration)` will fail

To fix this, change the assertion to
```
assert(first || lastReadVersion - ver >= SERVER_KNOBS->MAX_VERSIONS_IN_FLIGHT ||
				       lastReadVersion - ver < SERVER_KNOBS->VERSIONS_PER_SECOND * (25 + getDuration));

```

Test plan:
Apply to the fix on top of the commit reported by Joshua test. Rerun the command to make sure it passes.

This reverts commit c2939ba.

Change `StringRef()` to `""_sr`.

Co-authored-by: A.J. Beamon <[email protected]>

The ruby bindings are not currently installable. We can reproduce this
with a build from source:

```
foundationdb/tmp on  main [$?] via △ v3.25.2
zsh ❯ gem install ./bindings/ruby/fdb-7.3.0.gem
ERROR:  While executing gem ... (Gem::Package::PathError)
    installing into parent path /Users/andrew/projects/foundationdb/LICENSE of /Users/andrew/.rbenv/versions/3.2.1/lib/ruby/gems/3.2.0/gems/fdb-7.3.0 is not allowed
```

The problem is that the gemspec is interpolating the source directory
into the `files` array - and while this allows the gem to build, it
prevents it from actually being installed.

To fix it, we borrow similar code from the python bindings to copy the
necessary files and license into the build directory before building the
gem. This allows the gem to be installed:

```
foundationdb/tmp on  main [!?] via △ v3.25.2
zsh ❯ gem install ./bindings/ruby/fdb-7.3.0.gem
Successfully installed fdb-7.3.0
Parsing documentation for fdb-7.3.0
Installing ri documentation for fdb-7.3.0
Done installing documentation for fdb after 0 seconds
1 gem installed
```

While fixing the gem build, I noticed that the gem will not run on arm64
machines, like the new spiffy M1/M2 MacBooks. On a whim, I tried just
removing that restriction... and it does seem to work:

```
foundationdb/bindings/ruby/lib on  ahayworth/fix-ruby-binding-build [?] via 💎 v3.2.1 took 2s
zsh ❯ pry
[1] pry(main)> require 'fdb'
=> true
[2] pry(main)> FDB.api_version 720
LoadError: FoundationDB API only supported on x86_64 (not arm64)
from /Users/andrew/.rbenv/versions/3.2.1/lib/ruby/gems/3.2.0/gems/fdb-7.3.0/lib/fdbimpl.rb:40:in `<module:FDBC>'
[3] pry(main)>
```

…ite, the simulator could kill too many machines

…elliteTLogReplicationFactor and satelliteTLogUsableDcs. Update trace event with more info about the updated policy.

… proxies when getting key server locations

cherrypick multiple fixes [release-7.2]

Add compaction related knobs.

…verdbinfo-update-7.2

[Release 7.2] updateDBInfo.trigger() should trigger a new round of DbInfo update

By setting the latest version to 7.2.6

…st (apple#9872)

…free capacity check (apple#9892)

* Don't block the exclusion of stateless processes by the free capacity check

* Fix syntax

* Make use of precomputed exclude check

* Format code

* Only consider newly excluded processes

* Format code and update comment

* Don't stop iterating over all storage processes in exclusion check

* error logger

* recovery mode

It is not protocol compatible, revert it to avoid deployment issue.
Will have a new PR to have the feature if moving forward.

…pple#9759) (apple#10034)

…stead of bytelimit. (apple#9884)

# Conflicts:
#	fdbserver/KeyValueStoreRocksDB.actor.cpp
#	fdbserver/include/fdbserver/RocksDBCheckpointUtils.actor.h