Fix: plot_network bug due to changed networkx draw function behavior

[kbonney]

Summary

A change to the behavior the networkx function draw_networkx_edges disrupted the colorbar code in wntr's plot_network function due to a mismatch in return object.

The following code in draw_networkx_edges occurs in version 3.1 (probably 3.2 as well):

use_linecollection = not G.is_directed()
if arrows in (True, False):
    use_linecollection = not arrows

however this changes to the following in version 3.3:

if arrows is None:
    use_linecollection = not (G.is_directed() or G.is_multigraph())
else:
    if not isinstance(arrows, bool):
        raise TypeError("Argument `arrows` must be of type bool or None")
    use_linecollection = not arrows

The graph we use in plot_network is a multigraph, so use_linecollection now gets set to False, counter the the previous behavior. When this variable is false, the networkx function returns a list of FancyArrowPatches objects rather than a LineCollection object, which broke the way we handled colorbars. Additionally, it seems to change the plotting behavior so that the lines do not properly connect to nodes.

In this PR, arrows is set to equal the argument directed to achieve the original behavior. The old colormap code would be fixed as well with this change, but it depended on the output type from draw_networkx_edges so I opted for an approach that doesn't have this dependency.

Tests and documentation

I verified that the plots now look like they do when using networkx 3.1. I also added an extra figure to test_plot_network2 to cover the case when directed=True.

Acknowledgement

By contributing to this software project, I acknowledge that I have reviewed the software quality assurance guidelines and that my contributions are submitted under the Revised BSD License.

[kbonney]

Aha, I found the PR in networkx where this was introduced: networkx/networkx#7010. This was pulled in as part of the 3.3 release.