BUG/MEDIUM: h2: match absolute-path not path-absolute for :path

RFC7540 states that :path follows RFC3986's path-absolute. However
that was a bug introduced in the spec between draft 04 and draft 05
of the spec, which implicitly causes paths starting with "//" to be
forbidden. HTTP/1 (and now HTTP core semantics) made it explicit
that the request-target in origin-form follows a purposely defined
absolute-path defined as 1*(/ segment) to explicitly allow "//".

http2bis now fixes this by relying on absolute-path so that "//"
becomes valid and matches other versions. Full discussion here:

  https://lists.w3.org/Archives/Public/ietf-http-wg/2021JulSep/0245.html

This issue appeared in haproxy with commit 4b8852c70 ("BUG/MAJOR: h2:
verify that :path starts with a '/' before concatenating it") when
making the checks on :path fully comply with the spec, and was backported
as far as 2.0, so this fix must be backported there as well to allow
"//" in H2 again.

(cherry picked from commit 46b7dff8f08cb6c5c3004d8874d6c5bc689a4c51)
Signed-off-by: Willy Tarreau <w@1wt.eu>
diff --git a/src/h2.c b/src/h2.c
index bbc5853..dd1f7d9 100644
--- a/src/h2.c
+++ b/src/h2.c
@@ -279,6 +279,9 @@
 		/* 7540#8.1.2.3: :path must not be empty, and must be either
 		 * '*' or an RFC3986 "path-absolute" starting with a "/" but
 		 * not with "//".
+		 * However, this "path-absolute" was a mistake which was
+		 * later fixed in http2bis as "absolute-path" to match
+		 * HTTP/1, thus also allowing "//".
 		 */
 		if (unlikely(!phdr[H2_PHDR_IDX_PATH].len))
 			goto fail;
@@ -286,9 +289,6 @@
 			if (!isteq(phdr[H2_PHDR_IDX_PATH], ist("*")))
 				goto fail;
 		}
-		else if (phdr[H2_PHDR_IDX_PATH].len > 1 &&
-			 phdr[H2_PHDR_IDX_PATH].ptr[1] == '/')
-			goto fail;
 	}
 
 	if (!(flags & HTX_SL_F_HAS_SCHM)) {