MEDIUM: cfgparse: warn about proxies having the same names

As discussed below, there are too many problems and uncaught bugs
in the parser when trying to support proxies having similar names
but different types. There's specific code to detect the presence
of stick-tables in a pair of such proxies for example. It's even
possible that certain combinations of backend+listen that were not
previously detected have some nasty side effects.

According to the proposal in the discussion, this is now deprecated
in 3.1 (thus we emit a warning) and will become forbidden in 3.3.

A backport might be useful, but reporting a diag_warning only, not a
classical warning, so as not to break setups running in zero-warning
mode.

It was verified with a config involving all 9 combinations of
(frontend,backend,listen) followed by one of the same three that all
collisions are now properly blocked and that only back+front are kept
and emit a warning.

Link: https://www.mail-archive.com/[email protected]/msg45185.html

Author: wtarreau

src/cfgparse-listen.c

@@ -285,6 +285,16 @@ int cfg_parse_listen(const char *file, int linenum, char **args, int kwm)
 				 curproxy->id, curproxy->conf.file, curproxy->conf.line);
 				err_code |= ERR_ALERT | ERR_FATAL;
 		}
+		else {
+			curproxy = proxy_find_by_name(args[1], 0, 0);
+			if (curproxy) {
+				/* different capabilities but still same name: forbidden soon */
+				ha_warning("Parsing [%s:%d]: %s '%s' has the same name as %s '%s' declared at %s:%d. This is dangerous and will not be supported anymore in version 3.3.\n",
+				           file, linenum, proxy_cap_str(rc), args[1], proxy_type_str(curproxy),
+				           curproxy->id, curproxy->conf.file, curproxy->conf.line);
+				err_code |= ERR_WARN;
+			}
+		}
 
 		curproxy = log_forward_by_name(args[1]);
 		if (curproxy) {