`lastSuccessful` is ambiguous

[machty]

task.lastSuccessful points to the last Task Instance that ran to completion. When Task Modifiers (e.g. .drop()) are used (and concurrency is constrained to 1), then there's no ambiguity as to what this means, but for tasks with maxConcurrency > 1 (including the default unconstrained task configuration), there's a race condition / ambiguity / ordering issue where a newer (more recently-performed) task instance completes before an older task, resulting in the older Task Instance "overwriting" the newer TaskInstance as lastSuccessful.

This is probably not what we want; I think the lastSuccessful should never be overwritten with an older TaskInstance and we don't need to bother coming up with another property name by which we track the other kind of lastSuccessful (with the present behavior).

Alternatively, maybe there's a convention-over-configuration approach we could take here; maybe we could straight up prohibit access to lastSuccessful, etc, when concurrency hasn't been constrained? Usually that's a pretty big hint that somebody's messed up the configuration or left out a Task Modifier or something.

[tzellman]

Here is a Twiddle that I think highlights this concern.

[martletandco]

Could you make the distinction between 'performed' order and 'completed' order. lastSuccessful currently is referencing 'completed' order, where even if a Task Instance was the last to start, it might not be the last to finish, as demonstrated in the above Twiddle. So the expected behaviour in the demo could be had by binding to holdAndWait.performed.lastSuccessful (naming is hard)