WL#1719: CHANGE MASTER without purging existing relay logs (option)

Request from big customer. Quoting his reasons:
> 1) As far as I understand, if the slave is behind and you execute CHANGE
> MASTER on the slave, the slave will delete its relay logs and start
> replicating from the new position. It would be very useful if CHANGE
> MASTER would only repoint the IO thread, while the SQL thread continued to
> execute its relay logs. Here is why it's useful. Suppose you have a master
> and 20 slaves, where all slaves are several hours behind. If the master
> were to go down and we wanted to repoint all slaves to another master, we
> would have to wait until SQL thread caught up everywhere; only then would
> it be safe to execute CHANGE MASTER TO. It would be nice to CHANGE MASTER
> as soon as we know that the IO thread is caught up. The slaves would
> continue to execute the relay logs from the old master, then start
> executing statements on the new msater.

So simply it means when CHANGE MASTER happens, don't delete relay logs, just
start using a new one. So that the slave SQL thread can finish executing the old
logs while the I/O thread fetches the new ones. Proposed implementation:
in MySQL 4.1 I have already introduced a global variable
SET GLOBAL RELAY_LOG_PURGE= 0 or 1 (default is 1)
I could do this, starting from 4.1 :
- if RELAY_LOG_PURGE == 1, CHANGE MASTER will behave like now (purge relay logs)
- if RELAY_LOG_PURGE == 0, CHANGE MASTER will keep relay logs

The only complicated thing is that the CHANGE MASTER code is a bit strange and
so changing things into it might trigger unexpected bugs; the task in itself is
changing a few lines, but there is testing/debugging after that.