Recover from block stream issues

[LukasKorba]

Apparently the downloading of the blocks sometimes catches errors in ligthtwalletd server, those are most of the times represented as error 14 and our understanding is it happens sometimes and simple retry just work again and continues. The StateMachine in the CompactBlockProcessor ends up a sync when this happens and waits for another sync to trigger. That ne kicks in 20-30s and all work again and the sync continues. The problem is that we prolong the sync time by 20-30s and that makes it a bad UX.

The error

▿ ZcashError
  ▿ serviceBlockStreamFailed : LightWalletServiceError
    ▿ genericError : 1 element
      ▿ error : unavailable (14): The operation couldn’t be completed. (NIOHTTP2.NIOHTTP2Errors.StreamClosed error 1.), cause: StreamClosed(streamID: HTTP2StreamID(201), errorCode: HTTP2ErrorCode<0x8 Cancel>, location: "NIOHTTP2/HTTP2StreamChannel.swift:843")
        ▿ storage : <Storage: 0x600000c8f630>
        ▿ code : unavailable (14)
          - _rawValue : 14

▿ ZcashError
  ▿ serviceBlockStreamFailed : LightWalletServiceError
    ▿ genericError : 1 element
      ▿ error : unavailable (14): Transport became inactive
        ▿ storage : <Storage: 0x281fbc2a0>
        ▿ code : unavailable (14)
          - _rawValue : 14

The Goal

We should have a retry logic in place associated with the grpc calls for the downloads. In case the service is truly down, this must be done to only help with these false positive errors. I think 1-2 retries, first to happen almost immediately and the next one let's say in 1 second later should be enough to differentiate between service down and a flaw in the grpc/library/networking failure.