There's no reason to believe that the lock on the XID would not be
available, and if for reason it's not, it seems dangerous to just
continue as if nothing happened. So remove the GPDB-added code that
checked for that, reverting the function to the way it is in the upstream.

Because of the way the check was written, LockAcquire() always got called
twice, so we actually acquired the lock on the XID twice. That's usually
harmless, since both locks are released at the end of the transaction
anyway, except for one scenario: If you created a savepoint, and committed
it (e.g. with RELEASE SAVEPOINT), we would release the lock on the
subtransaction's XID only once, leaving the other lock still in place. So
we kept the lock on every committed subtransaction 'till the end of the
top transaction. That too was mostly harmless, the only ill effect was
that the locks would take some space in the global lock table, which is
limited in size, so you could run out of shared memory more easily if you
used subtransactions heavily.

Fixes github issue https://github.com/greenplum-db/gpdb/issues/7819