Cached condition results need to be keyed on status as well

Within the scope of an HttpServletRequest, ScriptRunner caches the results of any condition scripts that are run. The keys for this cache are derived from the condition arguments (i.e. the config data of the script item) and the key of the issue on which the condition is being evaluated. The essential upshot of this is that if the same condition is evaluated a second time on the same issue, as part of the same request, then the cached value from the first execution will be returned instead. Normally this is fine because there is almost no way for anything else to change between successive such evaluations, but one thing that can change is the issue's status.

To reproduce:

• Create a workflow with statuses S1, S2, S3 and transitions as follows:
  • T1 into S1 from elsewhere (could be the Create transition or a transition from another status S4, I don't think it matters)
  • T2 from S1 to S2.
  • T3 from S1 and S2 to S3.
• Set up fast-track transition post functions:
  • On T1 triggering T2.
  • On T2 triggering T3.
• Set up a transition condition on T3: issue.status.name != "S1" i.e. transition T3 cannot be performed from status S1*
• Create an issue under this workflow and perform the T1 transition on it.

* Obviously this would be pointless in a real-world scenario because we would be better off simply removing S1 as a possible source status for T3, but you can imagine more complicated conditions which would prevent transitioning from a status unless certain other criteria were met.

Expected result: The issue is fast-tracked through T2 into S2, then through T3 into S3 (allowed because its status isn't S1 at the point that T3 is performed).

Actual result: The issue is fast-tracked through T2 into S2 and stays there. There is a message in the logs indicating that transition T3 couldn't be performed because its condition returned false.

The false value here is cached from an earlier evaluation of the condition that occurs when ScriptRunner is performing the T2 fast-track from S1. SR queries the Jira API to ensure that T2 is a permissible transition, but the way that Jira determines this behind the scenes is by checking every transition from S1 for permissibility, collecting the ones that are permissible into a list, and then checking whether T2 is in that list. As part of this process, the condition on T3 is evaluated, and because the issue is still in S1 at this point the condition returns false.