* Update main branch to 7.4
* Update API version to 740
* Makes fdb_c_client_config_tests.py passing after API version update
* Remove from_7.3.0_until_7.4.0 and add from_7.3.0
* Update tests in fdb_c_client_config_tests.py
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)>
```
time checked on the proxy should be less than the time waited by the master to account for clock speed differences
setting REQUIRED_MIN_RECOVERY_DURATION and ENFORCED_MIN_RECOVERY_DURATION to 0 will go back to the old behavior
Because different bindings may issue different limit for get_range calls, it is
impossible to return the same size value for getApproximateSize API. So we just
push a string to make sure binding test results are the same. Use another unit
test to make sure the sizes got back are monotonically increasing.
Using int is troublesome because the size of int can be different from the
desired 64 bits. So, using a string representation seems to be more consistent.
Syed Paymaan Raza