Master-Slave is pretty good, but you must write only to the Master. Inability to write to the Master means inability to do the various tasks. A network outage between M and S leads to delayed updating of the Slave.
Master-Master, and writing to both, has several ways to get into trouble, so I recommend against it.
Master-Master, but writing to only one solves some of the M-M problems, and makes failover easier. That is, if the Master fails, the configuration is ready to promote the Slave in an otherwise M-S topology to be the Master.
Group Replication has a lot of promise, and is likely to be the best in the long run. However, I cannot say much at the moment.
MySQL NDB Cluster is complex to set up, has many moving parts, uses "eventual consistency" model of replication, etc. Some applications can use it; hard to say if it fits your situation. Study its implementation of "eventual consistency"; if that model works for you, then consider putting an instance of the three nodes (data, sql, mgt) on a single server at each of your two sites. (I assume scaling is not an issue.)
Galera (see MariaDB, Percona's PXC, or Codership), which you did not list, is robust, write-anywhere, self-healing, etc. The optimal setup would be to have 3, not 2, "nodes" in 3 separate locations with separate network connections. As long as any 2 nodes can talk to each other, those 2 declare themselves to be online. If the third is alive, but isolated (because of network outages), it understands that is should be "offline". When an offline node comes back online (from network outage or servers crash), the data is automatically repaired with the help of the online nodes.