detect/http: fix progress for headers keywords

[catenacyber]

Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/7326

Describe changes:

• detect/http: fix progress for headers keywords

SV_BRANCH=OISF/suricata-verify#2094

Should we have the generic fix of DetectAppLayerMultiRegister using only one tx progress ?

cf ce16a56 before which we already had the discrepancy

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.77%. Comparing base (378f678) to head (bf26f86).
Report is 8 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #11968   +/-   ##
=======================================
  Coverage   82.76%   82.77%           
=======================================
  Files         910      910           
  Lines      249014   249014           
=======================================
+ Hits       206105   206117   +12     
+ Misses      42909    42897   -12     

Flag	Coverage Δ
fuzzcorpus	60.78% <100.00%> (+<0.01%)	⬆️
livemode	18.70% <100.00%> (+<0.01%)	⬆️
pcap	44.10% <100.00%> (+0.25%)	⬆️
suricata-verify	62.17% <100.00%> (+<0.01%)	⬆️
unittests	59.01% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

[suricata-qa]

Information: QA ran without warnings.

Pipeline 23110

[victorjulien]

Please explain the problem and solution in the git message.

[catenacyber]

Please explain the problem and solution in the git message.

Tried something in #11977

But I think I explain rather a symptom (having a false negative in some scenario) than the full scope of the problem...

As for the solution : should we have the generic fix of DetectAppLayerMultiRegister using only one tx progress ?

Do you think "http.header" keyword has the same issue ?
What about "tls.subjectaltname" and "tls.alpn"` ? (which has an opposite issue : progress right for prefilter but not for inspect)