migration_manager: Propagate schema changes with reads like we do on …

…writes

This fixes the problem where the cordinator already knows about the
new schema and issues a read which uses new objects, but the replica
doesn't know those objects yet. The read will fail in this case. We
can avoid this if we propagate schema changes with reads, like we
already do for writes.

Message-Id: <20210205163422.414275-1-tgrabiec@scylladb.com>

service/migration_manager.cc

@@ -1092,7 +1092,7 @@ future<schema_ptr> get_schema_definition(table_schema_version v, netw::messaging
 }
 
 future<schema_ptr> get_schema_for_read(table_schema_version v, netw::messaging_service::msg_addr dst, netw::messaging_service& ms) {
-    return get_schema_definition(v, dst, ms);
+    return get_schema_for_write(v, dst, ms);
 }
 
 future<schema_ptr> get_schema_for_write(table_schema_version v, netw::messaging_service::msg_addr dst, netw::messaging_service& ms) {