Bug#11829838: ALTER TABLE NOT BINLOGGED WITH

--BINLOG-IGNORE-DB AND FULLY QUALIFIED TABLE
      
Problem:
=======
An ALTER TABLE statement is not written to binlog if server
started with "--binlog-ignore-db some database" and 'fully
qualified' table names are used in the ALTER TABLE statement
altering table different from current database context.
      
Analysis:
========
The above mentioned problem not only affects "ALTER TABLE"
statements but also to all kind of statements. Once the 
current default database becomes "NULL" none of the 
statements will be binlogged.
      
The current behaviour is such that if the user has specified
restrictions on which database needs to be replicated and the
default db is not specified, then do not replicate.
This means that "NULL" is considered to be equivalent to
everything (default db = null implied ignore don't log the
statement).
      
Fix:
===
"NULL" should not be considered as equivalent to everything.
Since the filtering criteria is not equal to "NULL" the
statement should be logged into binlog.

mysql-test/suite/rpl/r/rpl_loaddata_m.result:
  Earlier when defalut database was "NULL" DROP TABLE
  was not getting logged. Post this fix it will be logged
  and the DROP will fail at slave as the table creation
  was skipped by master as --binlog-ignore-db=test.
mysql-test/suite/rpl/t/rpl_loaddata_m.test:
  Earlier when defalut database was "NULL" DROP TABLE
  was not getting logged. Post this fix it will be logged
  and the DROP will fail at slave as the table creation
  was skipped by master as --binlog-ignore-db=test.
sql/rpl_filter.cc:
  Replaced DBUG_RETURN(0) with DBUG_RETURN(1).

mysql-test/suite/rpl/t/rpl_loaddata_m.test

@@ -46,7 +46,7 @@ SELECT COUNT(*) FROM mysqltest.t1;
 # Cleanup
 connection master;
 DROP DATABASE mysqltest;
-DROP TABLE test.t1;
+DROP TABLE IF EXISTS test.t1;
 sync_slave_with_master;
 
 # End of test