MEDIUM: http-rules: Support an optional error message in http deny rules

It is now possible to set the error message to use when a deny rule is
executed. It may be a specific error file, adding "errorfile <file>" :

  http-request deny deny_status 400 errorfile /etc/haproxy/errorfiles/400badreq.http

It may also be an error file from an http-errors section, adding "errorfiles
<name>" :

  http-request deny errorfiles my-errors  # use 403 error from "my-errors" section

When defined, this error message is set in the HTTP transaction. The tarpit rule
is also concerned by this change.
diff --git a/doc/configuration.txt b/doc/configuration.txt
index d12a3ae..93b9c65 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -4412,12 +4412,17 @@
   It takes one argument: "file name" It is the equivalent of the "del map"
   command from the stats socket, but can be triggered by an HTTP request.
 
-http-request deny [deny_status <status>] [ { if | unless } <condition> ]
+http-request deny [deny_status <status>] [ { errorfile | errorfiles } <err> ]
+                           [ { if | unless } <condition> ]
 
   This stops the evaluation of the rules and immediately rejects the request
   and emits an HTTP 403 error, or optionally the status code specified as an
   argument to "deny_status". The list of permitted status codes is limited to
-  those that can be overridden by the "errorfile" directive.
+  those that can be overridden by the "errorfile" directive. A specific error
+  message may be specified. It may be an error file, using the "errorfile"
+  keyword followed by the file containing the full HTTP response. It may also
+  be an error from an http-errors section, using the "errorfiles" keyword
+  followed by the section name.
   No further "http-request" rules are evaluated.
 
 http-request disable-l7-retry [ { if | unless } <condition> ]
@@ -4912,7 +4917,8 @@
   the frontend, the default mode is restored when HAProxy starts the backend
   rules evaluation.
 
-http-request tarpit [deny_status <status>] [ { if | unless } <condition> ]
+http-request tarpit [deny_status <status>] [ { errorfile | errorfiles } <err> ]
+                           [ { if | unless } <condition> ]
 
   This stops the evaluation of the rules and immediately blocks the request
   without responding for a delay specified by "timeout tarpit" or
@@ -4925,7 +4931,11 @@
   efficient against very dumb robots, and will significantly reduce the load
   on firewalls compared to a "deny" rule. But when facing "correctly"
   developed robots, it can make things worse by forcing haproxy and the front
-  firewall to support insane number of concurrent connections.
+  firewall to support insane number of concurrent connections. A specific error
+  message may be specified. It may be an error file, using the "errorfile"
+  keyword followed by the file containing the full HTTP response. It may also
+  be an error from an http-errors section, using the "errorfiles" keyword
+  followed by the section name.
   See also the "silent-drop" action.
 
 http-request track-sc0 <key> [table <table>] [ { if | unless } <condition> ]
@@ -5107,12 +5117,17 @@
   It takes one argument: "file name" It is the equivalent of the "del map"
   command from the stats socket, but can be triggered by an HTTP response.
 
-http-response deny [deny_status <status>] [ { if | unless } <condition> ]
+http-response deny [deny_status <status>] [ { errorfile | errorfiles } <err> ]
+                           [ { if | unless } <condition> ]
 
   This stops the evaluation of the rules and immediately rejects the response
   and emits an HTTP 502 error, or optionally the status code specified as an
   argument to "deny_status". The list of permitted status codes is limited to
-  those that can be overridden by the "errorfile" directive.
+  those that can be overridden by the "errorfile" directive. A specific error
+  message may be specified. It may be an error file, using the "errorfile"
+  keyword followed by the file containing the full HTTP response. It may also
+  be an error from an http-errors section, using the "errorfiles" keyword
+  followed by the section name.
   No further "http-response" rules are evaluated.
 
 http-response redirect <rule> [ { if | unless } <condition> ]