DOC: assorted typo fixes in the documentation

This is the fourth round of cleanups in various docs

contrib/modsecurity/README

@@ -1,7 +1,7 @@
 ModSecurity for HAProxy
 -----------------------
 
-This is a third party deamon which speaks SPOE. It gives requests send by HAProxy
+This is a third party daemon which speaks SPOE. It gives requests send by HAProxy
 to ModSecurity and returns the verdict.
 
   Compilation
@@ -24,8 +24,8 @@ the Apache dependencies are installed on the system.
 	cp standalone/*.h $PWD/INSTALL/include
 	cp apache2/*.h $PWD/INSTALL/include
 
-Note that this compilation method works, but is a litle bit rustic. I can't
-deal with Lua, I supposed that is a dependecies problem on my computer.
+Note that this compilation method works, but is a little bit rustic. I can't
+deal with Lua, I supposed that is a dependencies problem on my computer.
 
   Start the service
 ---------------------
@@ -113,7 +113,7 @@ Modsecurity bugs:
    -    rc = apr_global_mutex_create(&msce->auditlog_lock, NULL, APR_LOCK_DEFAULT, mp);
    +    rc = apr_global_mutex_create(&msce->auditlog_lock, NULL, APR_LOCK_PROC_PTHREAD, mp);
 
-* Configuration file loaded with wilcard (eg. Include rules/*.conf), are loaded
+* Configuration file loaded with wildcard (eg. Include rules/*.conf), are loaded
   in reverse alphabetical order. You can found a patch below. The ModSecurity
   team ignored this patch.
 

contrib/prometheus-exporter/README

@@ -4,14 +4,14 @@ PROMEX: A Prometheus exporter for HAProxy
 Prometheus is a monitoring and alerting system. More and more people use it to
 monitor their environment (this is written February 2019). It collects metrics
 from monitored targets by scraping metrics HTTP endpoints on these targets. For
-HAProxy, The Prometheus team offically supports an exporter written in Go
+HAProxy, The Prometheus team officially supports an exporter written in Go
 (https://github.com/prometheus/haproxy_exporter). But it requires an extra
 software to deploy and monitor. PROMEX, on its side, is a built-in Prometheus
 exporter for HAProxy. It was developed as a service and is directly available in
 HAProxy, like the stats applet.
 
 However, PROMEX is not built by default with HAProxy. It is provided as an extra
-component for everyone want to use it. So you need to explicity build HAProxy
+component for everyone want to use it. So you need to explicitly build HAProxy
 with the PROMEX service, using the Makefile variable "EXTRA_OBJS". For instance:
 
     > make TARGET=linux-glibc EXTRA_OBJS="contrib/prometheus-exporter/service-prometheus.o"
@@ -46,7 +46,7 @@ applet, all metrics are not grouped by service (proxy, listener or server). With
 PROMEX, all lines for a given metric are provided as one single group. So
 instead of collecting all metrics for a proxy before moving to the next one, we
 must loop on all proxies for each metric. Same for the servers. Thus, it will
-spend much more ressources to produce the Prometheus metrics than the CSV export
+spend much more resources to produce the Prometheus metrics than the CSV export
 through the stats page. To give a comparison order, quick benchmarks shown that
 a PROMEX dump is 5x slower and 20x more verbose than a CSV export.
 
@@ -99,7 +99,7 @@ Exported metrics
 | haproxy_process_pool_used_bytes                | Total amount of memory used in pools (in bytes).                              |
 | haproxy_process_pool_failures_total            | Total number of failed pool allocations.                                      |
 | haproxy_process_max_fds                        | Maximum number of open file descriptors; 0=unset.                             |
-| haproxy_process_max_sockets                    | Maximum numer of open sockets.                                                |
+| haproxy_process_max_sockets                    | Maximum number of open sockets.                                               |
 | haproxy_process_max_connections                | Maximum number of concurrent connections.                                     |
 | haproxy_process_hard_max_connections           | Initial Maximum number of concurrent connections.                             |
 | haproxy_process_current_connections            | Number of active sessions.                                                    |

contrib/spoa_server/README

@@ -79,7 +79,7 @@ Main process:
 
 Python:
 
- * Improve repporting: Catch python error message and repport it in the right
+ * Improve reporting: Catch python error message and report it in the right
    place. Today the error are dumped on stdout. How using syslog for logging
    stack traces ?
 

doc/internals/initcalls.txt

@@ -62,7 +62,7 @@ make sure to respect this ordering when adding new ones.
   are serialized by the init_mutex, so that locking is not necessary in these
   functions. There is no relation between the thread numbers and the callback
   ordering. The function is expected to return non-zero on success, or zero on
-  failure. A failure will make the process emit a succint error message and
+  failure. A failure will make the process emit a succinct error message and
   immediately exit. See also hap_register_per_thread_free() for functions
   called after these ones.
 
@@ -110,7 +110,7 @@ make sure to respect this ordering when adding new ones.
   current one, the sequence of _alloc() and _init() calls will be atomic. There
   is no relation between the thread numbers and the callback ordering. The
   function is expected to return non-zero on success, or zero on failure. A
-  failure will make the process emit a succint error message and immediately
+  failure will make the process emit a succinct error message and immediately
   exit. See also hap_register_per_thread_alloc() for functions called before
   these ones.
 
@@ -123,7 +123,7 @@ make sure to respect this ordering when adding new ones.
   that would preferably not be done on the fly to avoid inducing extra time to
   a pure configuration check. Threads are not yet started so no protection is
   required. The function is expected to return non-zero on success, or zero on
-  failure. A failure will make the process emit a succint error message and
+  failure. A failure will make the process emit a succinct error message and
   immediately exit.
 
 - void hap_register_post_deinit(void (*fct)())
@@ -148,7 +148,7 @@ make sure to respect this ordering when adding new ones.
   worth being aware that such a function must be careful not to waste too much
   time in order not to significantly slow down configurations with tens of
   thousands of backends. The function is expected to return non-zero on
-  success, or zero on failure. A failure will make the process emit a succint
+  success, or zero on failure. A failure will make the process emit a succinct
   error message and immediately exit.
 
 - void hap_register_post_server_check(int (*fct)(struct server *))
@@ -160,7 +160,7 @@ make sure to respect this ordering when adding new ones.
   careful not to waste too much time in order not to significantly slow down
   configurations with tens of thousands of servers. The function is expected
   to return non-zero on success, or zero on failure. A failure will make the
-  process emit a succint error message and immediately exit.
+  process emit a succinct error message and immediately exit.
 
 - void hap_register_proxy_deinit(void (*fct)(struct proxy *))