Uses of retry_delay() in transactions can be problematic

We call this to get a default constant delay before retrying something, typically.   This leads to issues as we often are calling something recursively, and will eventually blow our stack.   Initially this issue cropped up, and we instead made the pause a fraction (1/100) of the expiry, to limit this to 100 retries max.   However, this is (a) arbitrary, and (b) now causing issues in Jenkins (maybe always was).   

Lets instead work around this by not calling recursively, and instead redesigning around a pattern that loops, is tail recursive, etc...

Note - I will lower that number to 50, just to get Jenkins stable, in the meantime.