Regular AbstractProject builds have a loop for retrying SCM checkouts when they fail throwing IO Exceptions. This retry loop is useful, because in certain circumstances the git server may disconnect, such as the following exception:

 
ERROR: Error fetching remote repo '<REMOTE>'
hudson.plugins.git.GitException: Failed to fetch <URL>
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:812)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1079)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1110)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:130)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:59)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:262)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:405)
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress <URL> <REFSPEC>" returned status code 128:
stdout:
stderr: key_load_public: invalid format
Received disconnect from <SERVER> port <PORT>: Too many concurrent connections
Connection to <SERVER> closed by remote host.
fatal: Could not read from remote repository.
Basically, sometimes this server gets too much load and decides to disconnect the clones. Unfortunately this behavior can't be fixed on that end, and thus the retry loop is the only way to catch this.

In regular pipelines, I can write pipeline code which does the retry for myself. However, I'm unable to do this for the checkout step that occurs as part of fetching the pipeline code.

Is it possible to add the retry logic to the checkout step so that it will attempt to retry the checkout when it fails under this disconnection?