[Feature] Resume ES on latest block

[sschiessl-bcp]

User Story
As a provider of an elasticsearch API I want more control on how the plugin resumes its work such that ciritcal errors don't cause a downtime of several days.

The plugin has the --elasticsearch-start-es-after-block and --es-objects-start-es-after-block option. If the backend node feeding ElasticSearch goes down unrelated to the elasticsearch plugin, setting an option to "discover yourself where to continue" would be neat. To be precise: The elasticsearch plugin looks up what the last available block is in the database, and resume insertion from that block.

Impacts
Describe which portion(s) of BitShares Core may be impacted by your request. Please tick at least one box.

• API (the application programming interface)
• Build (the build process or something prior to compiled code)
• CLI (the command line wallet)
• Deployment (the deployment process after building such as Docker, Travis, etc.)
• DEX (the Decentralized EXchange, market engine, etc.)
• P2P (the peer-to-peer network for transaction/block propagation)
• Performance (system or user efficiency, etc.)
• Protocol (the blockchain logic, consensus, validation, etc.)
• Security (the security of system or user data, etc.)
• UX (the User Experience)
• Other (please add below)

Additional Context (optional)
Add any other context about your request here.

CORE TEAM TASK LIST

• Evaluate / Prioritize Feature Request
• Refine User Stories / Requirements
• Define Test Cases
• Design / Develop Solution
• Perform QA/Testing
• Update Documentation

[abitmore]

Since the parameters can be set via command line, it is not hard to write a script to fetch the last available block from ES and append corresponding parameters to the command which starts the node. Note: it would be wise to start from a few blocks back to mitigate chain reorganization issue.

So IMHO "won't fix".

By the way, normally when an insertion to ES fails, the node should hang there retrying again and again. If the node is stopped and restarted at that time, it will continue from the last irreversible block, but not even need a replay (this causes issue #2493). One exception is #2241 which would be fixed with #2242. Another exception is a crash.