Provide an API to get storages initialization state

[psergee]

There is an issue with using CRUD functionality if not all storages are
up. New function is added to get the information about storages
state: initialized or not. So, a user can poll state and wait for
storages to be initialized before making CRUD calls.

Looks like state.lua module is unused. Removed.

Resolves #229

[DifferentialOrange]

Original ticket discusses some possibility to implement simple retries, while this solution provide a manual handle to check the state. Was this design approved by issue authors or product managers? Also, to be honest, I don't think current approach to state check is satisfying (see comments).

[psergee]

Original ticket discusses some possibility to implement simple retries, while this solution provide a manual handle to check the state. Was this design approved by issue authors or product managers? Also, to be honest, I don't think current approach to state check is satisfying (see comments).

We have discussed this approach with Java connector team and @Totktonada
Currently we could not come up with a better option to provide the information about CRUD storage init state. Timeout approach does not look useful, because storage start may take a long time and CRUD calls like select or get will "hang" if timeout is big enough. In case of small timeout, the original issue will not fade away.

[DifferentialOrange]

Thank you, LGTM!

I'll merge it after #232 . Maybe you'll need to rebase this PR and solve remaining conflict before merge.

[Totktonada]

Original ticket discusses some possibility to implement simple retries, while this solution provide a manual handle to check the state. Was this design approved by issue authors or product managers?

Discussed between me, Pavel. S and cartridge-java developers. We agreed that a function that will return status of storages will suit the needs.

I can share my vision of the problem. There are a bit different situations:

1. Waiting for the cluster boostrap (full or partial).
2. Run queries.

There are different possible mechanisms that can help in those situations:

1. A status endpoint.
2. Timeouts for queries.
3. Contract on errors that allows a client to spot the non-bootstrapped storage situation and retry.

Timeouts for queries is the most used mechanish and it allows to overcome small periods of a peer unavailability. We support it, but there are flaws: #95.

The also unified error messages for the non-bootstrapped storage case, see PR #296 and PR #297. (It is not great that we propose to match the error message to make programmatic decisions, but errors in crud -- and even in tarantool itself -- requires a redesign and rework IMHO. At least, some revision.)

However we still don't offer anything to wait for a potentially long times (over usual query timeout) until the cluster will go into the ready state. It is what we want to solve here.

[Totktonada]

Thanks! The patchset is okay for me in general. However, please, consider several comments and thoughts.

[DifferentialOrange]

Since there are some GitHub folding, maybe you've missed these unresolved comments so I'll write them down here:

• Provide an API to get storages initialization state #299 (comment)
• Provide an API to get storages initialization state #299 (comment)
• Provide an API to get storages initialization state #299 (comment)
• Provide an API to get storages initialization state #299 (comment)