Use the code position on decision completion to improve auto-reset experience

[longquanzheng]

Currently auto-reset is like a nuclear bomb, it will kill many innocent people. It reset all the progress made by the bad deployment, even though some progress doesn't run into any bad code. If we have the code position in the decision result, we can only reset the workflow that runs into the bad code position(provided by customer).

Lets say our customer has two workflow definitions: wf1.go and wf2.go. and Somehow his deployment B1 has a bug in wf2.go at line # 1000, If we use auto-reset with B1 as bad deployment, it will reset all workflows even only one workflow run into this line # 1000 and generating bad state. Also if B1 is the very first deployment, then auto-reset B1 will reset all existing workflows to the first decision(for both wf1.go and wf2.go), which is very heavy and side effecty.

On the other hand, if we store the code position in decision detail, we can reset the workflows that has made decision at wf2.go at # 1000. Which is ideal for reset bad binary case.

Instead of a nuclear bomb, we will have a guided missile to kill only bad guys

[longquanzheng]

related to #2801