Maximum Transactions in JobQueue read from Config

[natenichols]

High Level Overview of Change

Fixes #3556. max_transactions is now read from the rippled.cfg instead of hardcoded.

Context of Change

The maximum capacity of JobQueue was hardcoded in PeerImp.cpp. Now the maximum capacity is read from the configuration file. max_transactions defaults to 250, and has a hardcoded minimum of 100 and a hardcoded maximum of 1000, as suggested in the issue description.

This option is added to the configuration with:

[max_transactions]
    500

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)
• Tests (You added tests for code that already exists, or your new feature included in this PR)
• Documentation Updates
• Release

Before/After

Before:
max_transactions was hardcoded.

After:
MAX_TRANSACTIONS is read from rippled.cfg in Config.cpp. std::clamp is used to ensure the configuration value is between 100 and 1000. Member variable max_transactions_ was created in PeerImp, and initialized to the value read by the configuration.

Test Plan

All unit tests pass. No tests added.

[nbougalis]

Very nice! Thanks for your first contribution and also for being mindful enough to edit the example configuration file to reflect the new tunable.

I left a small comment that should be trivial to address.

You should also consider renaming your commit message to adhere to best practices. I recommend:

Make the transaction job queue limit adjustable

[nbougalis]

Consider instead:

if (app_.getJobQueueCount().getJobCount(jtTRANSACTION) > app_.config().MAX_TRANSACTIONS)

Rationale: the variable is only set in one place and isn't "per-peer" so this lets you eliminate the unnecessary member variable, and highlights the intent of the code.

[pwang200]

Looks good and works fine!