Multixact and prepared transactions

While reviewing the hot standby patch, I noticed a little existing bug
with multixacts and prepared transactions. If a prepared transaction has
a shared lock on a tuple, represented by a multixact, other backends can
sometimes update the tuple anyway.

Steps to reproduce, using two psql sessions:

CREATE TABLE foo (id int4);
INSERT INTO foo VALUES (1);

In session 1:

-- lock the tuple for the first time.
postgres=# begin; SELECT xmax,xmin, * from foo FOR SHARE;
BEGIN
xmax │ xmin │ id
──────┼──────┼────
713 │ 667 │ 1
(1 row)

-- leave the transaction open

In session 2:

-- lock the tuple the 2nd time, turning xmax into a multixact.
postgres=# begin; SELECT * FROM foo FOR SHARE; PREPARE TRANSACTION 'foo';
BEGIN
id
────
1
(1 row)

PREPARE TRANSACTION

In session 1:

postgres=# commit;
COMMIT
-- the prepared transaction is now the only live member of the multixact

postgres=# UPDATE foo SET id=id; -- This should block waiting on the
prepared xact!
UPDATE 1

We seem to have neglected prepared transactions in the logic that tracks
the oldest visible multixact. OldestMemberMXactId doesn't contain
entries for prepared transactions, so the UPDATE incorrectly considers
the multixact as an old obsolete one.

A straightforward fix is to enlarge OldestMemberMXactId to make room for
max_prepared_transactions extra entries, and at prepare transfer the
value of the current backend to one of those slots.

- Heikki