Restructure block listener retry configuration

[Chengxuan]

Move the block listener retry configuration outside the retry attribute as that was for resty client retry. Having them together is confusing.

[Chengxuan]

@EnriqueL8 Migration logic added, ready for another look

[EnriqueL8]

After looking the PR - I think bigger changes are needed here. So we use these delay and retry configurations across three things:

• Block Listener
• Event Listener
• Event Stream

If we are deciding to split one, we should split them all to be configurable. Right not this PR proposes only splitting block listeners but those configurations still apply to the other two which is odd

[Chengxuan]

@EnriqueL8 thanks for the question. Even though the retry object appeared in the 3 different concepts you listed above, the loop it controls all serves the same purpose: to resume the listener processes that all require making further JSON-RPC queries. Because normally when one of them hits an issue, the others will likely suffer the same issue, having a consistent retry setting makes sense. So a single configuration for all makes sense and avoids giving users too many toggles before it's necessary.

I'll pick a better name for the configuration to make that clear.

[Chengxuan]

@EnriqueL8 ready for another look again

[EnriqueL8]

Makes sense now! Thanks for the clarification @Chengxuan