stack/erp5: Replicate based on slave_pos, not current_pos

The query present in the sql dump sets gtid_slave_pos, which is used by
slave_pos. current_pos relies on gtid_current_pos, which is not set here
and hence fails to initiate replication.
Another (unintended) effect of using slave_pos is that queries run on the
slave will not break replication. There should be no reason to run queries
on slave (at least, data & schema modification queries while replication
is active), so it would seem better to fail the replication immediately in
order to detect this. So this may not be the best solution - but at least
this fixes this script.

stack/erp5/buildout.hash.cfg

@@ -22,7 +22,7 @@ md5sum = 0c0d98a68230cd0ad36046bb25b35f4a
 
 [mariadb-start-clone-from-backup]
 filename = instance-mariadb-start-clone-from-backup.sh.in
-md5sum = e405227118a70fbf949a6414469989db
+md5sum = d95e8500bdc72d1f40b97cc414656e7e
 
 [template-mariadb]
 filename = instance-mariadb.cfg.in

stack/erp5/instance-mariadb-start-clone-from-backup.sh.in

@@ -89,7 +89,7 @@ zcat "$BACKUP" | "$CLIENT" -u root
 echo "Configuring server as slave..."
 if [ "$MASTER_USE_GTID" -eq 1 ]; then
   "$CLIENT" -u root -e "$SQL_SET_GTID"
-  MASTER_USE_GTID_SQL="current_pos"
+  MASTER_USE_GTID_SQL="slave_pos"
 else
   MASTER_USE_GTID_SQL="NO"
 fi