Avoid TF 2.2 bug via 'binary_accuracy' metric in GCN link prediction (#1770)
Avoid TF 2.2 bug via 'binary_accuracy' metric in GCN link prediction (#1770)

This works around a change in behaviour of `metrics=["acc"]` in TensorFlow 2.2
(https://github.com/tensorflow/tensorflow/issues/41361) by replacing that with
`metrics=["binary_accuracy"]`. All other changes here are just from rerunning
the notebook.

Previously, in TF 2.0 and 2.1, the `acc`/`accuracy` metric was being translated
into `binary_accuracy`, because the `compile` method was noticing that the loss
function was `binary_crossentropy`. In TF 2.2, the inference for
`acc`/`accuracy` no longer looks at the loss function, and instead just relies
on the last dimension of the prediction tensor: if the dimension is equal to 1,
it uses binary accuracy, otherwise categorical accuracy. (See #1766 and
https://github.com/tensorflow/tensorflow/issues/41361 for more details.)

This GCN link prediction demo uses the binary crossentropy loss function, but
has a `Reshape((-1,))` layer, that removes the natural last dimension of size 1,
leaving a predictions tensor with last dimension of size 2708 (number of nodes
in the graph). This means that the inference of the true metric for the `acc`
name was changing from the correct `binary_accuracy` in TF 2.1 to the incorrect
`categorical_accuracy` in TF 2.2.

(Another option would be removing the `Reshape((-1,))` layer, leaving the last
dimension of size 1, but I decided that this could have large knock-on
consequences.)

(I looked for other instances of `Reshape((-1,))` and `Flatten()` layers that
hit this same problem, but it seems like the others are fine. For instance,
https://github.com/stellargraph/stellargraph/blob/f0590c0bed1a482f63ef1cd10e42fdba62ff8685/demos/link-prediction/homogeneous-comparison-link-prediction.ipynb
uses `metrics=["binary_accuracy"]` directly.)

Fixes: #1766

stellargraph/stellargraph,stellargraph/stellargraph