Consider adding a retry mechanism for out-of-memory error codes

[jpalmer37]

I have encountered rare cases where a run appears to fail due to running out of memory during the kraken process. It appears to be a consistent error code of 137.

For the FluViewer_nf pipeline, we temporarily implemented the following retry mechanism for a memory-heavy process. I was thinking something similar could be applicable here for kraken:

process kraken {
  memory  { (70 + 10 * task.attempt) GB }   # ** not tested **
  errorStrategy { (task.exitStatus == 137 && task.attempt <= maxRetries) ? 'retry' : 'ignore' } 
  maxRetries 3
  
  ...
}

This pattern is also referenced here: https://seqera.io/blog/error-recovery-and-automatic-resources-management/