Fix "retry" in simpleflow History

[jbbarth]

This PR is based on #423, so please only review the last 2 commits (I wish I had a better way to do that, see #424)

The "retry" count in simpleflow's History model is wrong:

• 1/ it's set at the end of each activity, when failing or timing out, so it has a wrong value during executions
• 2/ it's set to "0" when a task fails or times out, which means it's off by one (if a task fails then succeeds, "retry" is at "0" instead of "1")

This PR:

• (first commit) fixes the two issues by setting it at "schedule" time for activities (and "start_initiating" time for child workflows)
• (second commit) adds a "attempts" key to materialise attempts ; tbh I would drop "retry" and keep that one only, as I find it clearer to understand ; that's the wording AWS SDKs use fwiw ; but we can decide to drop this second commit if you prefer

[ewjoachim]

It's sure that it would be nice if we didn't have to keep to equivalent properties. I guess there might be a way to only keep a single value and use getter/setters to expose the other one. But it's probably going to be highly overengineered compared to your solution. It's just that I'm afraid we may end up in cases where they're out of sync, especially if there's client code interacting with those.

So I'd say OK, but I think we'll may need to change details here and there in our own code in relation to this. I'd suggest we do this in a different release, after the boto thing.

[jbbarth]

@ewjoachim honestly I would keep only "attempts" as it's semantically clearer than "retry", BUT I'm afraid of breaking in some usages. If you're not afraid of breaking (I know for a fact it's not used in Webflow, and I doubt you use the history in the Botify codebase...) we can get rid of it?

Also we used to love dicts, I agree that some dataclasses with more intelligent serialisation would be great.

[ybastide]

Maybe we could use the attempt_number name, as in simpleflow.task.TaskFailureContext?
And update this class not to use retry? 🙂