ExecuteQuery() is not supported on leveldb state
database.  Currently if called it will panic the peer.
This changeset changes it to a normal error
so that it does not kill the peer process.

Change-Id: Ib9f525524c99b107b4fc3935f2d38a5657bace73
Signed-off-by: denyeart <enyeart@us.ibm.com>

Motivation for this change:
Maintain the version inline with the document, without changing the
structure/value of the stored document.  This will prevent unexpected
data values being returned and will prevent possible name collisions
with document values.

- Create a data wrapper for ledger JSON data stored in CouchDB.

- Return the version based on block number and transaction id

The wrapper will be implemented as a new key named "data" which will
contain the JSON data for the state database.

Prior to change example:

"doc": {
 "_id": "2",
 "_rev": "2-8ee0c31b21ad650e5b872c0b98e59ab5",
 "version":"1:2"
 "asset_name": "marble2",
 "color": "red",
 "owner": "tom",
 "size": "25"
}

 Following change:

 "doc": {
  "_id": "2",
  "_rev": "2-8ee0c31b21ad650e5b872c0b98e59ab5",
  "version":"1:2"
  "data": {
   "asset_name": "marble2",
   "color": "red",
   "owner": "tom",
   "size": "25"
  }
 }

Change-Id: I59391ea926531c46c346fc8448e3d041ca5f3fdf
Signed-off-by: Chris Elder <chris.elder@us.ibm.com>

- Utilize leveldb for history of keys instead of couchdb

- Single leveldb database serves all chains to optimize
  footprint (same structure as leveldb block index database
  and leveldb state database)

- Block commit writes a history key for each key/value
  that is updated in a tran, in the form:
   ns~key~blocknum~trannum

- History database is an index for history of key writes
  over time.  The key values are not included to reduce
  size of database.

- GetHistoryForKey() finds all records starting with ~ns~key
  and returns the transactions that updated the key.

- Subsequent changeset will lookup and return the txid
  and historic value from the block storage.  Client can
  then GetTransactionById to see the historic transactions.

- Since history db size is much reduced, it is now enabled
  by default in core.yaml.

- Upon crash recovery, ledger initialization will ensure
  that both state db and history db in sync with block storage

Reused existing test logic, therefore the changeset
is relatively large to ensure tests still pass.

Change-Id: I79103aa39957f58d246de5b5295fb40a4b9c033b
Signed-off-by: denyeart <enyeart@us.ibm.com>

https://jira.hyperledger.org/browse/FAB-1668



Phantom reads problem:
-----------------------------
If a transaction executes a key range query (say key_1 - key_n) leveldb
serves all the keys in the given range in sorted order of keys.
Between simulation and validation of a transaction, some other transaction
may insert one or more keys in this range. Now, this change cannot
be detected by merely checking the versions of the keys present in
the read-set of the transaction.
(though, this check can detect updates and deletes).

A serializable isolation level does not permit phantom reads.

Situations where the phantom reads may not be acceptable:
-----------------------------
 - A chaincode may take a decision based on aggregates of the results of
the range query such as min/max/avg/sum etc. This would be affected
if a new entry gets added to the range query results.

 - A chaincode may want to change all the marbles
owned by a specific user to blue in a tran `t1`. The chaincode may do so
by performing a range query to get all the marbles for the user and
change their color to blue. Now, if a new white marble get added to
the user's assets by an another transaction `t2`,
`t1` should be marked as invalid.

Solution in this change-set:
-----------------------------
For solving this, we can capture the details of the range query
(the query and it's results) during the simulation time and
re-execute the query during validation time and compare the results.
If the results (keys and versions) are still the same,
we can safely commit the transaction.

This changes set introduces
 - Structures for capturing the range query details in rwset
 - Detection of phantom items (insertion/deletion)
   that affect the results of the range query during validation
 - Mark the transactions that are affected by the phantom items
   as invalid to ensure serializability in the presence of range queries

Change-Id: I909841a0234c37795ad7a4ffcca8a9ebd9c9f994
Signed-off-by: manish <manish.sethi@gmail.com>

https://jira.hyperledger.org/browse/FAB-1664



This changeset:
- Renames package ledger/util/db to ledger/util/leveldbhelper
- Implements a leveldb provider
  (that enables using same leveldb instance as a multiple logical dbs)
  in util package for being able to reuse across statedb, index,
  and later for historydb
- Implements a provider as a single point of invocation
  for managing multiple block storage
- Uses a single leveldb instance for block storage index
- Makes the structures other than providers as private
  to their respective packages

Change-Id: I5f0b3b9aa8ef3ac1ccdce4f3c6fa6d842b5318c1
Signed-off-by: manish <manish.sethi@gmail.com>

When chaincode is deployed, it fills the peer debug log with
many megabytes of binary dumps, making it difficult to
troubleshoot through the noise.

Change-Id: I7be1814632f0fda272b10793e7e6413b7d1de0e4
Signed-off-by: denyeart <enyeart@us.ibm.com>

FAB-1505 refactors CouchDB code to be aligned with LevelDB structure.
FAB-1337 applies all ledger tests written for LevelDB against CouchDB.

In order to test the CouchDB refactor,
had to implement FAB-1337 in same changeset to test.

Like most refactors, this changeset touches a lot of files and code,
since it is not feasible to do a partial refactor.

Tests related to versioning and deleting have been commented out,
these will be re-enabled in subsequent changeset when CouchDB
has the support, in order to keep this changeset size more reasonable.

Change-Id: I0d2d6cca89bd0252f6e84317457a9140b3a0d7a5
Signed-off-by: denyeart <enyeart@us.ibm.com>

https://jira.hyperledger.org/browse/FAB-1543



Change-Id: Ib11d1a2fc14cf81dd5380eadf93e73e1c56113e3
Signed-off-by: manish <manish.sethi@gmail.com>

https://jira.hyperledger.org/browse/FAB-602



The refactoring allows sharing of transaction execution and validation code across goleveldb and couchdb.
This refactoring also allows plugging-in different schemes for various aspects of transaction execution
such as maintianing isolation during simulation, validation and commit.

Change-Id: I0d3fb1cdff99c3f6f991e7b7469920173f194a87
Signed-off-by: manish <manish.sethi@gmail.com>