Diagnose incompatible OpenLDAP versions during build and test.

With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
backends can crash at exit.  Raise a warning during "configure" based on
the compile-time OpenLDAP version number, and test the crash scenario in
the dblink test suite.  Back-patch to 9.0 (all supported versions).

contrib/dblink/sql/.gitignore

@@ -0,0 +1 @@
+/paths.sql

contrib/dblink/sql/dblink.sql

@@ -78,6 +78,30 @@ SELECT *
 FROM dblink('SELECT * FROM foo') AS t(a int, b text, c text[])
 WHERE t.a > 7;
 
+-- The first-level connection's backend will crash on exit given OpenLDAP
+-- [2.4.24, 2.4.31].  We won't see evidence of any crash until the victim
+-- process terminates and the postmaster responds.  If process termination
+-- entails writing a core dump, that can take awhile.  Wait for the process to
+-- vanish.  At that point, the postmaster has called waitpid() on the crashed
+-- process, and it will accept no new connections until it has reinitialized
+-- the cluster.  (We can't exploit pg_stat_activity, because the crash happens
+-- after the backend updates shared memory to reflect its impending exit.)
+DO $pl$
+BEGIN
+	PERFORM wait_pid(crash_pid)
+	FROM dblink('dbname=contrib_regression', $$
+		SELECT pg_backend_pid() FROM dblink(
+			'service=test_ldap dbname=contrib_regression',
+			-- This string concatenation is a hack to shoehorn a
+			-- set_pgservicefile call into the SQL statement.
+			'SELECT 1' || set_pgservicefile('pg_service.conf')
+		) t(c int)
+	$$) AS t(crash_pid int);
+EXCEPTION WHEN sqlclient_unable_to_establish_sqlconnection THEN
+	-- Expect "syntax error in service file" in a non-LDAP build.
+END
+$pl$;
+
 -- create a persistent connection
 SELECT dblink_connect('dbname=contrib_regression');