Path workers, allow node operators to configure threads used

[shortthefomo]

High Level Overview of Change

Introduce a new configurable limit for pathfinding workers ([path_workers]), replacing the previous jt_update_pf_limit. This allows administrators to control the maximum number of concurrently running jtUPDATE_PF jobs in the JobQueue, which impacts path update and full order book update throughput. The limit is now capped at 3/4 of the configured [workers] (rounded down), with a minimum cap of 2, to prevent system overload while allowing better utilization of available threads.

Additionally, tie the number of pathfinding threads (mPathFindThread) dynamically to the configured workers, ensuring scalability.

This change does heavily impact a node CPU use when configured away from the default.

Context of Change

The pathfinding thread count is now tied to workers to avoid fixed low limits that don't scale. This improves performance on larger deployments while preventing resource exhaustion.

The core finding is that because pathfinding and order books updates are blocked behind a single thread, all other requests on todo that get stuck behind the slowest request. As xrpld stands today.

It is recommended that pathfinding nodes do run in memory mode along with this patch #6549

Every effort has been made to make sure the node is not starved when servicing large number of requests. Even so a validator should not be configuring their node to discover paths. This config is meant only for node setup to discover paths.

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)

No API impact - this is purely a configuration change.

Before / After

Before:

• jt_update_pf_limit was limited to 1
• Pathfinding threads: Fixed at 1 and Job Queue of Fixed minimum of 2, not tied to workers
• Limiting the pathfinding operation effetely to 1 thread where all requests stack up if a longer pathfinder operation is added to the node effectively everyone using the node has to wait for it.

After:

• Config option: [path_workers] (default 2, max 3/4 of workers rounded down, min cap 2)
• Limit cap: 3/4 of workers (min 2), enforced at runtime
• Allows multiple threads to service the requests, where by if a longer running path find operation on the node is requested not everyone is stuck waiting for that to complete.

Example: With [workers] = 14, max [path_workers] is now 10 (vs. previous 1).

Test Plan

• Build verification: Code compiles successfully with CMake.
• Config validation: Invalid values (e.g., > 3/4 workers) are rejected with clear error messages.
• Runtime behavior: Server starts with valid configs and enforces limits dynamically.

To test: Set [path_workers] to a value > 3/4 of [workers] and verify startup failure with appropriate error.

Future Tasks

None - this completes the pathfinding worker configurability improvements.

*mixed up branches was working on and totally messed up #6604 so this PR is fixing that.