Implement a safety check mechanism on object_database, based on the
safety_check_policy abstract interface. Create two standard
implementations of the safety_check_policy interface, one
(null_safety_check) which allows all modifications unconditionally, and
the other (database_lock_safety_check) which allows modifications only
when unlocked.
Integrate these safety checks into chain::database and plugins, so that
the consensus databases are locked at all times except during core
consensus code pathways. Also ensures that databases are re-locked when
calling code outside of consensus pathways from consensus pathways.
To make this work, it was necessary to move two objects from the
consensus object spaces to a new API object space. The
operation_history_object and account_transaction_history_object were
moved to the API object space, as they are not actually used by
consensus and are maintained by a plugin (which can no longer modify the
consensus object spaces, due to the safety checks).
Finally, add a mechanism to application and chain::database, which
allows the chain to start in "unit testing mode" and allows unchecked
actions upon the database within delimited scopes. This was necessary
because many tests edit the database directly to set up the environment
for their respective tests. This mode is activated by database_fixture so
tests can utilize it conveniently, but it is architecturally difficult to
enable this mode in production, i.e. from a plugin.
Pursuant to the requested safety checks on the database, to ensure that
plugin code (i.e., third party code) cannot modify the database, we
implement evaluator tagging so the chain can distinguish between
consensus evaluators and third party evaluators. Also, define a new kind
of evaluator base class, third_party_evaluator, so that fees are not
charged multiple times for operations with multiple evaluators.
Next step, implement the actual safety check mechanism on the database.
Create a new cli_wallet command, run_custom_operation, which makes it
convenient to run custom_operation transactions which invoke third party
contracts (i.e., dapps)
When using an external genesis file, it doesn't make sense to calculate
the chain ID as the literal text contents of the file, which are quite
volatile. Rather, it should be calculated based on the logical content
of the file. Serialize the genesis object to get a canonical
representation, and calculate the chain ID off of that.
The count_objects_in_space function, while providing the necessary
functionality, was clumsy and inconvenient, and was not idiomatic.
Replace it with inspect_all_indexes which resolves these shortcomings.
