Decreased the 'phase' values where variable(s) allow(s)

[airween]

Decreased the phase values where variable activated the previous phase - eg. REQUEST_FILENAME available in phase:1, not necessary to wait to 2nd phase (body processing). All changes are from phase:2 to phase:1, except in case of rule 950100, which is a response rule - there the old phase value is 4, now it's 3.

[dune73]

I have looked through all the changes in this PR by hand and I have not found a problem.

It looks like all the changes are valid and we do not lose anything by shifting to phase:1 in these situations. This looks very good.

I did not check the remaining phase:2 rules so I can not tell whether some of them could still be moved to phase:1, but I presume this is not the case.

[airween]

I did not check the remaining phase:2 rules so I can not tell whether some of them could still be moved to phase:1, but I presume this is not the case.

I've collected the variables by a script, and checked the variables and the phases where they waked. The "target" phase became the highest value - except the collection variables, like TX or IP - I skipped them.

The untouched rules are in right phases I guess.

[dune73]

I am positive this is the case, not the least because you did work by script.

Where I am a bit weary is skipAfter happening in the wrong phase now. But I checked all the rule-exclusion packages and they are correct in this regard. So I think we are OK.

[fzipi]

Did an additional review also, and haven't found a problem. This is a very good PR!

[dune73]

Thank you, @fzipi.

We're ready to merge, but since this is a significant change, we'll keep it on the agenda for tonight. There are also other questions around the underlying issue. And we should discuss those.

[dune73]

Meeting decision (#1944 (comment)): This will be merged once the new conflict is resolved.

[airween]

Conflict had resolved.

[dune73]

Thank you for your quick reaction and the patch. Merging now.