Allow querying of assets with filters

[sschiessl-bcp]

User Story As a developer I want to get assets matching certain criterias without having to query all and filter locally so that the network and processing load is reduced, for client and server.

Possible filters (may combine as pleases):

• asset type (uia, bitasset, prediction market, anything else?)
• simple regex search for symbol (only define * as any)
  • *X: any asset that ends with X
  • YYYY.*: any asset under the namespace YYYY, or starts with YYYY. (equivalent)
  • YY*: any asset starting with YY (includes also YYYY.X)
  • YY: any asset that has YY somewhere in the symbol
  • *.BTC: All assets that ends with .BTC (should return OPEN.BTC, BRIDGE.BTC etc, but NOT OPEN.BBTC)
• list of asset issuers (nice to have, would facilitate loading of trusted issuers)
• list of asset holders (nice to have, would speed up loading all assets for one user)

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

• [x] 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)

Additional Context (optional) Facilitate loading and filtering from UI, and reduce load on nodes.

CORE TEAM TASK LIST

• [ ] Evaluate / Prioritize Feature Request
• [ ] Refine User Stories / Requirements
• [ ] Define Test Cases
• [ ] Design / Develop Solution
• [ ] Perform QA/Testing
• [ ] Update Documentation

[abitmore]

Giving the complexity, I guess it's easier to query via ES.

[sschiessl-bcp]

Easier for the coder, yes. Easier for the UI and world wide availability, no.

ES is still not adopted globally, I don't see it happen any time soon due to the server requirements. ES shines when historical information are needed. This feature requires current state only.

I vote for direct core support. The regex could be reduced to a simple searchTerm in assetSymbol match.

As an unsatisfying alternative: Remove regex filter capabilities and add a flag that returns only an id-name list of all assets instead of full details, and matching is done locally.

[pmconrad]

Regex has inherent dangers. Simple prefix/suffix matching would be safe though and work for all your examples. (And it'd be easy to implement as well.)

[abitmore]

ES is still not adopted globally, I don't see it happen any time soon due to the server requirements.

Put this on witnesses' back. Or workers. Just Politics.

On the other hand, UI should start making use of ES. If the main user doesn't use ES, why ask people to setup servers?

[abitmore]

returns only an id-name list of all assets instead of full details, and matching is done locally.

This is easy to implement. Deal?

[sschiessl-bcp]

returns only an id-name list of all assets instead of full details, and matching is done locally.

This is easy to implement. Deal?

I woudl rather have the search logic in core in the way that Peter mentioned, but if I can't have that then I will settle for that easy way. You guys decide :)

[abitmore]

While I was working on adding API for this issue, I found some code in database_api.* annoying, so ended up with #1891. Will continue working on this.