MEDIUM: http: restrict the HTTP version token to 1 digit as per RFC7230

While RFC2616 used to allow an undeterminate amount of digits for the
major and minor components of the HTTP version, RFC7230 has reduced
that to a single digit for each.

If a server can't properly parse the version string and falls back to 0.9,
it could then send a head-less response whose payload would be taken for
headers, which could confuse downstream agents.

Since there's no more reason for supporting a version scheme that was
never used, let's upgrade to the updated version of the standard. It is
still possible to enforce support for the old behaviour using options
accept-invalid-http-request and accept-invalid-http-response.

It would be wise to backport this to 1.5 as well just in case.
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 780d6b5..6728644 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -4108,7 +4108,7 @@
                                  yes   |    yes   |   yes  |   no
   Arguments : none
 
-  By default, HAProxy complies with RFC2616 in terms of message parsing. This
+  By default, HAProxy complies with RFC7230 in terms of message parsing. This
   means that invalid characters in header names are not permitted and cause an
   error to be returned to the client. This is the desired behaviour as such
   forbidden characters are essentially used to build attacks exploiting server
@@ -4121,7 +4121,9 @@
   chars 0-31, 32 (space), 34 ('"'), 60 ('<'), 62 ('>'), 92 ('\'), 94 ('^'), 96
   ('`'), 123 ('{'), 124 ('|'), 125 ('}'), 127 (delete) and anything above are
   not allowed at all. Haproxy always blocks a number of them (0..32, 127). The
-  remaining ones are blocked by default unless this option is enabled.
+  remaining ones are blocked by default unless this option is enabled. This
+  option also relaxes the test on the HTTP version format, it allows multiple
+  digits for both the major and the minor version.
 
   This option should never be enabled by default as it hides application bugs
   and open security breaches. It should only be deployed after a problem has
@@ -4147,7 +4149,7 @@
                                  yes   |     no   |   yes  |   yes
   Arguments : none
 
-  By default, HAProxy complies with RFC2616 in terms of message parsing. This
+  By default, HAProxy complies with RFC7230 in terms of message parsing. This
   means that invalid characters in header names are not permitted and cause an
   error to be returned to the client. This is the desired behaviour as such
   forbidden characters are essentially used to build attacks exploiting server
@@ -4155,7 +4157,9 @@
   server will emit invalid header names for whatever reason (configuration,
   implementation) and the issue will not be immediately fixed. In such a case,
   it is possible to relax HAProxy's header name parser to accept any character
-  even if that does not make sense, by specifying this option.
+  even if that does not make sense, by specifying this option. This option also
+  relaxes the test on the HTTP version format, it allows multiple digits for
+  both the major and the minor version.
 
   This option should never be enabled by default as it hides application bugs
   and open security breaches. It should only be deployed after a problem has