add negative rate test

[dangell7]

High Level Overview of Change

The negative rate has different results across different operating systems. I've observed the following;

Mac: -1.0 is handled as 0

When this is handled as 0 the result is tesSUCCESS

Nix & Windows: -1.0 is handled as 3294967296 and therefore the result is temBAD_TRANSFER_RATE

I don't believe anyone is running this on mac in production however the issue should still be resolved.

Context of Change

Type of Change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Refactor (non-breaking change that only restructures code)
• [ ] Performance (increase or change in throughput and/or latency)
• [ ] Tests (you added tests for code that already exists, or your new feature included in this PR)
• [ ] Documentation update
• [ ] Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
• [ ] Release

API Impact

• [ ] Public API: New feature (new methods and/or new fields)
• [ ] Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• [ ] libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• [ ] Peer protocol change (must be backward compatible or bump the peer protocol version)

[shortthefomo]

can attest ive run rippled on a Mac in production

[bthomee]

@dangell7 Do you have a fix in mind for this issue?

[ximinez]

The negative rate has different results across different operating systems.

As far as I can tell, this is a unit test problem, and not a transaction engine problem.

Specifically,

1. The initializer list builds test_results objects, the first field of which is double set.
2. doTests builds the jtx using rate(alice, r.set).
3. rate (defined in src/test/jtx/impl/rate.cpp) takes that value as double multiplier.
4. The field is set as: jv[jss::TransferRate] = std::uint32_t(1000000000 * multiplier);, which converts the double into an unsigned int. That is UB.

Possible solutions.

1. Don't do that!
2. Convert the value to int32_t. a. Use static_cast instead of C-style cast, just for readability.
3. Check for negative in rate and fail.