More intuitive/natural/easier to understand retries...

So a couple of ideas that I've been having here:

Thought #1, retry atoms are connected to a flow yet they are stored as an atom detail derivative, this seems odd. If they are 1:1 to a flow then couldn't we just store the information that is now being stored in retry details in the flow detail objects themselves? This would imply we would have to store all the flow details that are in a flow (one for each nested flow as well), this is a bigger change onto itself so might not be reasonable (or will have to be done incrementally over a set of releases); although another way is to just rename retry details to be 'nested flow details' and denote that nested flow details are 'markers' and will not themselves contain children references (aka references to there contained atoms...)

Thought #2, stop having retries be connected to flows directly and just let them be used as arbitrary atoms that can be placed at any location in a flow. At compilation time we are already decomposing the flow/s (and by association the retry) and just placing it in the graph before other atom/s that the contained flow contains or is connected to (and then associating the edges correctly to represent this). It might just make sense to let retries be attached as any other atom, as a part of the flow that can execute and revert as any other task can.... This removes the decomposition that happens with the current compilation routine and just lets users do this manually as they see fit... This might be semantaically weird though, what does it mean for a flow to just have R1 -> R2 -> R3 (where all of these are retries) without any actually tasks....

Thought #3, support a simple decorator syntax that can be attached on tasks that will allow for *single* task specific retrying, it will not be persisted (aka no retry details will be created for it to retain this information) but it would/could be useful to make it simple to have an engine know how to do single task retries without involving the more complicated full retry mechanism (maybe call this simple retries or something). This allows the engine to be aware of and perform the retrying when this decorator is attached, the only other recommended way would be to tell people to use https://pypi.python.org/pypi/retrying in there execute() method which then hides the retrying from the engine (which is likely not the direction we want to go/have people use).

Thought #4, determine if the persistence of retries is useful via retry details, and evaluate if the current mechanism has been benefical or has it been to limiting, and if it isn't useful, remove that functionality and instead have more advanced functionality that isn't required to be persisted (akin to #3 but also removing code that isn't being found that benefical...) or investigate some other mechanism that may help in the future...