A new test for the fix for BUG#4500 ("SET CHARACTER SET replicates incorrectly").

As I cannot be 100% sure that there won't be issues with some of our exotic platforms
(who knows if the charset of <obscure old OS> will play fair?), I'll send an email to the build guys.
Well, this holds if bk does not crash on binary chars of this cset.

mysql-test/r/rpl_set_charset.result

+slave stop;
+drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
+reset master;
+reset slave;
+drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
+slave start;
+drop database if exists mysqltest1;
+create database mysqltest1 /*!40100 character set latin2 */;
+use mysqltest1;
+drop table if exists t1;
+create table t1 (a varchar(255) character set latin2, b varchar(4));
+SET CHARACTER SET cp1250_latin2;
+INSERT INTO t1 VALUES ('','80');
+INSERT INTO t1 VALUES ('','90');
+INSERT INTO t1 VALUES ('','A0');
+INSERT INTO t1 VALUES ('','B0');
+INSERT INTO t1 VALUES ('','C0');
+INSERT INTO t1 VALUES ('','D0');
+INSERT INTO t1 VALUES ('','E0');
+INSERT INTO t1 VALUES ('','F0');
+select "--- on master ---";
+--- on master ---
+--- on master ---
+select hex(a),b from t1 order by b;
+hex(a)	b
+A9A6ABAEAC	80
+B9B6BBBEBC	90
+A3A1AAAF	A0
+B3B1BAA5B5BF	B0
+C0C1C2C3C4C5C6C7C8C9CACBCCCDCECF	C0
+D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF	D0
+E0E1E2E3E4E5E6E7E8E9EAEBECEDEEEF	E0
+F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF	F0
+show binlog events from 1979;
+Log_name	Pos	Event_type	Server_id	Orig_log_pos	Info
+master-bin.001	1979	Query	1	1979	use `mysqltest1`; SET CHARACTER SET DEFAULT
+use mysqltest1;
+select "--- on slave ---";
+--- on slave ---
+--- on slave ---
+select hex(a),b from t1 order by b;
+hex(a)	b
+A9A6ABAEAC	80
+B9B6BBBEBC	90
+A3A1AAAF	A0
+B3B1BAA5B5BF	B0
+C0C1C2C3C4C5C6C7C8C9CACBCCCDCECF	C0
+D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF	D0
+E0E1E2E3E4E5E6E7E8E9EAEBECEDEEEF	E0
+F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF	F0
+drop table t1;

mysql-test/t/rpl_set_charset.test

+source include/master-slave.inc;
+--disable_warnings
+drop database if exists mysqltest1;
+# 4.1 bases its conversion on the db's charset,
+# while 4.0 uses the part of "SET CHARACTER SET" after "_".
+# So for 4.1 we add a clause to CREATE DATABASE.
+create database mysqltest1 /*!40100 character set latin2 */;
+use mysqltest1;
+drop table if exists t1;
+--enable_warnings
+create table t1 (a varchar(255) character set latin2, b varchar(4));
+SET CHARACTER SET cp1250_latin2;
+INSERT INTO t1 VALUES ('ŠŒŽ','80');
+INSERT INTO t1 VALUES ('šœžŸ','90');
+INSERT INTO t1 VALUES ('£¥ª¯','A0');
+INSERT INTO t1 VALUES ('³¹º¼¾¿','B0');
+INSERT INTO t1 VALUES ('ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏ','C0');
+INSERT INTO t1 VALUES ('ÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß','D0');
+INSERT INTO t1 VALUES ('àáâãäåæçèéêëìíîï','E0');
+INSERT INTO t1 VALUES ('ðñòóôõö÷øùúûüýþÿ','F0');
+select "--- on master ---";
+select hex(a),b from t1 order by b;
+# It's complicated to verify that the charset is reset to default in
+# the binlog after each query, except by checking the binlog. When you
+# merge this into 4.1/5.0, the 1979 will have to be changed; all you have
+# to do is read the var/log/master-bin.0*01 with mysqlbinlog, verify
+# that a SET CHARACTER SET DEFAULT is just after the last INSERT, and
+# replace 1979 by its position (the "# at" line above the SET).
+show binlog events from 1979;
+save_master_pos;
+connection slave;
+sync_with_master;
+use mysqltest1;
+select "--- on slave ---";
+select hex(a),b from t1 order by b;
+connection master;
+drop table t1;
+save_master_pos;
+connection slave;
+sync_with_master;