ShardingRuleConfiguration.getLogicTableNames() omits auto tables so they are not reloaded after DROP SHARDING TABLE RULE

Bug Report

Which version of ShardingSphere did you use?

master @ 101c3d56ccd

Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?

Both

Expected behavior

ShardingRuleConfiguration.getLogicTableNames() returns the logic table names of both tables and autoTables, so a dropped auto table is reloaded like a standard one.

Actual behavior

Only tables is mapped. In Cluster mode, DROP SHARDING TABLE RULE <auto_table> reaches ClusterMetaDataManagerPersistService.removeRuleConfigurationItem with an empty needReloadTables, so the table's schema metadata is not reloaded; the same statement on a DATANODES(...) rule reloads it. In Standalone mode GenericSchemaBuilder builds no loader material for the auto table.

Reason analyze (If you can)

#34906 added this override (ShardingRuleConfiguration.java line 72-74) together with the Broadcast, Encrypt, Mask and Single ones, which return every table they hold. ShardingTableNamesRuleAttribute and DropShardingTableRuleExecutor already include auto tables.

Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.

Cluster mode:

1. CREATE SHARDING TABLE RULE t_order(STORAGE_UNITS(ds_0,ds_1),SHARDING_COLUMN=order_id,TYPE(NAME='hash_mod',PROPERTIES('sharding-count'='4')));
2. DROP SHARDING TABLE RULE t_order;

Example codes for reproduce this issue (such as a github link).

ShardingRuleConfiguration ruleConfig = new ShardingRuleConfiguration();
ruleConfig.getAutoTables().add(new ShardingAutoTableRuleConfiguration("t_order", "ds_0,ds_1"));
ruleConfig.getLogicTableNames(); // empty, expected [t_order]