Dns over http2 5773 v3

[catenacyber]

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

Describe changes:

• analyze DNS over HTTP2

SV_BRANCH=pr/1540

OISF/suricata-verify#1540 rebased and force-pushed

Draft to get feedback about approach...
Leaving comments on the code for specific questions

#10040 with

• needed rebase
• do not parse if doh2 is disabled in suricata.yaml
• log so that CI should not be red for the moment

TODO :

• Fix dns json schema and logging first (that is https://redmine.openinfosecfoundation.org/issues/6281 )
• Use config for dns logging...
• Merge Output alert applayer v17.1 #9870 so as not to have a short-lived output-json-doh2.c

Functionnaly, in terms of output :

• The flow will have doh2 as app_proto (and http2 as app_proto_orig)
• There are doh2 events that have both http2 and dns fields. dns logging is done like alerts, not like dns events...
• DNS and HTTP and HTTP2 signatures work on DOH2
• Signatures can be DOH2 specific. These signatures can combine http, http2 and dns keywords.
• DNS Frames do not work on DoH2

Memory management

• a HTTP2 tx can own 2 DNS tx (one to client, one to server)
• a HTTP2 tx stores the streamed DNS response content until it is complete before parsing it (limiting to U16_MAX bytes)

API

• There is a new DOH2 app-layer protocol which resorts to HTTP2 for most of the things
• HTTP2 parsing discovering DOH2 changes the app_proto to DOH2, doh2 can be enabled or disabled in suricata.yaml config
• There are more alproto "comparison" functions
• Every DNS keyword needs to check the flow alproto to change the transaction
• Every DNS/HTTP keyword is automatically registered for DOH2 (hacking DetectAppLayerMpmRegister2...)

[suricata-qa]

Information: QA ran without warnings.

Pipeline 17339

[catenacyber]

Replaced by #10123