Peer handling of ledger initilization failures

This issue is being opened for a design consideration for Hyperledger Fabric 2.x or above regarding how the peer handles the failure to initialize a ledger. Currently, if ledger initialization fails (such as due to issues with the state database) the peer will continue running and there are not automatic recovery efforts related to that one ledger.

In the current design of the peer, there is a contrast between how failures writing to the state database (CouchDB) are handled for normal operations and during peer initialization.
1. During normal operations, if there is a problem writing to the state database and retries are exhausted, progress cannot be made on the channel and the peer will panic so it restarts with the hope that the state database problem has resolved.
2. However, in the case of peer initialization, if it is not possible to update the state database and retries are exhausted, then the peer does not panic. This is by design as unavailability of one ledger could impact the availability of other ledgers which might have initialized successfully.

The request of this issue is for a design change to the peer that would automatically start recovery actions if one ledger cannot load. Following are a couple of suggested approaches.
1. If one ledger does not load, then cause the peer to panic. Whether the peer chooses to panic in this situation could be controlled by a peer configuration parameter that could be set.
2. Add an additional set of retries for the ledger initialization process with a time-based back off strategy in hopes that it will eventually succeed on a retry if problems related to the state database have been resolved.