book_changes API method doesn't follow standard ledger selection rules

[mDuo13]

Issue Description

The book_changes API method requires you to specify a ledger version, but doesn't follow the standard conventions for doing so:

• It does not support shortcut strings such as "ledger_index": "validated"
• If you do not specify either ledger_index or ledger_hash it fails with an error instead of choosing a ledger by default
  • To match other API methods' behavior in rippled, the default should be the current ledger.

Steps to Reproduce

1. Connect to a rippled (not Clio) server
2. Send the following request:

   {
     "id": "book_changes_by_shortcut",
     "command": "book_changes",
     "ledger_index": "validated"
   }

Same applies for current and closed ledger shortcuts.

Choosing a ledger by default

Same as above, but the request is as follows:

{
  "id": "book_changes_use_default",
  "command": "book_changes"
}

Expected Result

Response uses the latest validated/current/closed ledger as specified, or uses an appropriate default.

Actual Result

If using a shortcut string, the API returns an error such as the following:

{
  "error": "invalidParams",
  "error_code": 31,
  "error_message": "Invalid field 'ledger_index'.",
  "id": "book_changes_by_shortcut",
  "request": {
    "command": "book_changes",
    "id": "book_changes_by_shortcut",
    "ledger_index": "validated"
  },
  "status": "error",
  "type": "response"
}

If the ledger was not specified, the API returns an error such as the following:

{
  "error": "invalidParams",
  "error_code": 31,
  "error_message": "Exactly one of ledger_hash and ledger_index can be set.",
  "id": "book_changes_use_default",
  "request": {
    "command": "book_changes",
    "id": "book_changes_use_default"
  },
  "status": "error",
  "type": "response"
}

Environment

Tested using the xrplcluster.com servers running 2.2.0-rc1, but I think this API hasn't been changed much if at all since #4212 two years ago so the problems probably exist in older versions.

The s1.ripple.com cluster mostly goes to Clio servers, which don't have this bug.

See Also

#5033
#5035