Error messages for APIs should be clearer

[abitmore]

Bug Description

Due to #1903 and related code changes, the error messages returned by the APIs are less clear than before. The error message or data need to include the value of the configured limit, otherwise the clients won't know what the limit is.

Sample response produced by old versions (with info that the limit parameter should be <= 1000):

$ curl -d '{"id":1,"method":"call","params":["database","lookup_accounts",["test",10000]]}' https://api.bts.mobi/ 2>/dev/null |jq
{
  "id": 1,
  "error": {
    "code": 10,
    "message": "Execution error",
    "data": {
      "code": 10,
      "name": "assert_exception",
      "message": "Assert Exception",
      "stack": [
        {
          "context": {
            "level": "error",
            "file": "database_api.cpp",
            "line": 687,
            "method": "lookup_accounts",
            "hostname": "",
            "thread_name": "th_a",
            "timestamp": "2020-04-10T15:43:02"
          },
          "format": "limit <= 1000: ",
          "data": {}
        }
      ]
    }
  }
}

Sample response produced by current code in release branch (with no info about what the limit should be):

$ curl -d '{"id":1,"method":"call","params":["database","lookup_accounts",["test",10000]]}' http://127.0.0.1:8090 2>/dev/null |jq                                                                                                                                                                     
{
  "id": 1,
  "error": {
    "code": 10,
    "message": "Execution error",
    "data": {
      "code": 10,
      "name": "assert_exception",
      "message": "Assert Exception",
      "stack": [
        {
          "context": {
            "level": "error",
            "file": "database_api.cpp",
            "line": 688,
            "method": "lookup_accounts",
            "hostname": "",
            "thread_name": "th_a",
            "timestamp": "2020-01-29T12:07:48"
          },
          "format": "limit <= _app_options->api_limit_lookup_accounts: ",
          "data": {}
        }
      ]
    }
  }
}

All similar APIs need to be fixed.

Impacts
Describe which portion(s) of BitShares Core may be impacted by this bug. Please tick at least one box.

• API (the application programming interface)
• Build (the build process or something prior to compiled code)
• CLI (the command line wallet)
• Deployment (the deployment process after building such as Docker, Travis, etc.)
• DEX (the Decentralized EXchange, market engine, etc.)
• P2P (the peer-to-peer network for transaction/block propagation)
• Performance (system or user efficiency, etc.)
• Protocol (the blockchain logic, consensus, validation, etc.)
• Security (the security of system or user data, etc.)
• UX (the User Experience)
• Other (please add below)

CORE TEAM TASK LIST

• Evaluate / Prioritize Bug Report
• Refine User Stories / Requirements
• Define Test Cases
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[abitmore]

The app_options parameter of database_api constructor was initially designed to be optional. When omitted, nullptr will be stored in the implementation class. At that time, the code always checks whether the stored pointer is nullptr when trying to dereference the pointer.

However, it has changed at some time point. In current code base, the pointer is dereferenced at many places without a nullptr check, specifically, mostly the code about configurable API limits. The related test cases all construct database_api objects with an explicit non-null app_options parameter.

We need to fix it, either by requiring the parameter to be non-null and non-optional (which means to change quite some code), or always checking if it's nullptr (which means to change quite some other code). Update: I've decided to go with the 2nd approach.

[abitmore]

Fixed by #2154.