xml_is_well_formed (was Re: buildfarm warnings)

I wrote:
> This conversation motivated me to take a fresh pass over said filtering
> script, and one thing I notice that it's been ignoring is these complaints
> from all the AIX animals:

> ld: 0711-224 WARNING: Duplicate symbol: .xml_is_well_formed
> ld: 0711-224 WARNING: Duplicate symbol: xml_is_well_formed

> while building contrib/xml2. Evidently this is because xml2 defines
> a symbol also defined in the core. We cannot rename xml2's function
> without a user-visible ABI break, but it would be pretty painless
> to rename the core function (at the C level, not SQL level).
> So I propose we do that.

I tried to do that, but it blew up in my face, because it turns out that
actually contrib/xml2's extension script has a by-C-name reference to
the *core* function:

-- deprecated old name for xml_is_well_formed
CREATE FUNCTION xml_valid(text) RETURNS bool
AS 'xml_is_well_formed'
LANGUAGE INTERNAL STRICT STABLE PARALLEL SAFE;

The situation with the instance in xml2 is explained by its comment:

* Note: this has been superseded by a core function. We still have to
* have it in the contrib module so that existing SQL-level references
* to the function won't fail; but in normal usage with up-to-date SQL
* definitions for the contrib module, this won't be called.

So we're faced with a dilemma: we can't rename either instance without
breaking something. The only way to get rid of the warnings seems to be
to decide that the copy in xml2 has outlived its usefulness and remove
it. I don't think that's a hard argument to make: that version has been
obsolete since 9.1 (a0b7b717a), meaning that only pre-extensions versions
of xml2 could need it. In fact, we pulled the trigger on it once before,
in 2016 (20540710e), and then changed our minds not because anyone
lobbied to put it back but just because we gave up on the PGDLLEXPORT
rearrangement that prompted the change then.

I think that getting rid of these build warnings is sufficient reason
to drop this ancient compatibility function, and now propose that
we do that.

regards, tom lane