Fix scaling loops caused by change in scalingNeeded logic

[waquidvp]

Fixes #1194.

Reverts the following commit d2df308 which is causing the behavior explained in the above issue.

Not 100% if this is the correct fix, especially seeing the comment in the function. It might fix the loop, but might brake something else that is relying on the current behavior.

[tgross]

Thanks for hunting this down @waquidvp. For context, the comment here is referring to the Dynamic Application Sizing (DAS) feature of the Enterprise code base. In DAS, the sdk.ScalingAction will have a count, but the direction is none. The second part of the comment

for vertical and horizontal policies checking the direction is enough

That seems like that should be enough, because why would we get a difference in count if the direction is "none"? But clearly we're getting non-"none" direction along with no difference in count, because that's the symptom being displayed in #1194.

That makes me think:

• If we're going to fix this issue here, we should drop the direction check entirely because it's apparently meaningless.
• Or, perhaps better yet, we should try to figure out how we're getting a non-none direction if the count hasn't changed.