The database API is huge, messy and inconsistent

_From @theoreticalbts on September 24, 2015 17:47_

Problems in the database API:

```
(1) vector> get_accounts(const vector& account_ids)const;
(2) vector> lookup_account_names(const vector& account_names)const;
(3) vector> lookup_asset_symbols(const vector& symbols_or_ids)const;
```

Accounts have different functions (1)-(2) to get accounts.
Assets have a single function (3) which accepts symbols or stringified ID's.

```
(4) optional get_account_by_name( string name )const;
```

Accounts have a function (4) to get a single account by name, everything else uses vectors.

```
(5) std::map get_full_accounts( const vector& names_or_ids, bool subscribe );
```

get_full_accounts (5) gets the account object and associated objects, nothing else has anything similar. It would
be useful to have other queries which fetch an object and all related objects, e.g. given a BitAsset,
fetch the asset object, BitAsset data structure, and the asset object for the base asset.

```
(6) vector list_assets(const string& lower_bound_symbol, uint32_t limit)const;
(7) vector get_call_orders(asset_id_type a, uint32_t limit)const;
(8) map lookup_witness_accounts(const string& lower_bound_name, uint32_t limit)const;
```

Methods (6), (7), and (8) do the same thing but have different names.

```
(9) vector get_limit_orders(asset_id_type a, asset_id_type b, uint32_t limit)const;
(10) vector get_call_orders(asset_id_type a, uint32_t limit)const;
(11) vector get_settle_orders(asset_id_type a, uint32_t limit)const;
```

Methods (9), (10), and (11) have no way to request later pages. Furthermore, on reading the code,
the limits are not enforced by some of these methods.

```
(12) * @param limit Maximum number of results to return -- must not exceed 1000
(13) * @param limit Maximum number of assets to fetch (must not exceed 100)
```

Maximum number of things to query should be consistent and enforced. We
may want to provide local wrappers for methods which return iterators, possibly
with latency hiding (e.g. instead of having it block for the whole round trip
when you reach the end of the iterator, instead have it send off the request
for the next page when the iterator reaches the halfway point of the current
page).

The database API needs to be refactored, broken apart into multiple simpler API's. The sections in `database_api.hpp` could conceivably be separately implemented (although we need some kind of union API to make them all accessible to clients under API ID 0).

_Copied from original issue: cryptonomex/graphene#338_