Verify Signatures API Call

[mvandeberg]

The API will be in database_api (For master and develop) with the following format:

verify_signatures_return verify_signatures( const verify_signatures_args& args )const;

struct verify_signatures_args
{
   fc::sha256                       hash;
   vector< signature_type >         signatures;
   vector< account_name_type >      accounts;
   authority::classification        auth_level; //owner, active, posting
};

struct verify_signatures_return
{
   bool valid;
};

The hash can be of anything. For any given hash, set of signatures, set of accounts, and authority level the API will return if the signatures are sufficient based on the account's authorities. To match behavior of steemd transaction signing, it will fail on duplicate signatures, but will throw an exception on that failure rather than silently fail by returning false.

[mvandeberg]

The commit history needs cleaned up as a result of review in #1726 in order to facilitate comprehensive auditing of critical consensus code.

There are two design requirements that motivated the design that exists.

1. We want the Steem auth system to be usable for third party signature verification.
2. It is best practice for the payload of those signatures to not be something that would be valid on the blockchain.
3. The current auth verification only works on operations (things that are valid on the blockchain).

The design is to template the current auth verification to work on any objects that implement the following interface or a static_variant of objects that all implement the interface. The former is the new API arguments and the later is the current format of operations in Steem.

void get_required_authorities( vector<authority>& )const;
void get_required_active_authorities( flat_set<account_name_type>& )const;
void get_required_posting_authorities( flat_set<account_name_type>& )const;
void get_required_owner_authorities( flat_set<account_name_type>& )const;

The transformation from the current source code to the properly abstracted source code should be logical, incremental, and build-able at each stage (to prove compatibility via CI).

[mvandeberg]

These updates now need to be merged back in to develop.

[theoreticalbts]

Is there a reason this ticket is still open?

[mvandeberg]

Sorry, I meant master.

An older version of this was merged to master. The develop PR is the one that you had problems with, which forced a refactor of the branch. That now needs to be merged back in to master.