[ENH] Implement minimal m-separator functionality for enumerating minimal m-separators and also checking if separating set is minimal

[jaron-lee]

Fixes #34

Changes proposed in this pull request:

• Implements a function to detect minimal m-separators (if any) in a graph

Before submitting

• I've read and followed all steps in the Making a pull request
  section of the CONTRIBUTING docs.
• I've updated or added any relevant docstrings following the syntax described in the
  Writing docstrings section of the CONTRIBUTING docs.
• If this PR fixes a bug, I've added a test that will fail without my fix.
• If this PR adds a new feature, I've added tests that sufficiently cover my new functionality.

After submitting

• All GitHub Actions jobs for my pull request have passed.

[jaron-lee]

@adam2392 when you get a chance - I tried implementing minimal m-separators according to the Van der Zander paper. They have an example in figure 5 which I have written tests for. I have a failing test for minimal_m_separators(G, "X", "Y", i={"Z_1"}) in that graph.
I think I have implemented the algorithm (FINDMINSEP) correctly as it is written down in the paper, but there seems to be some issues with it generally? For example, when computing Z'' it's possible that the algorithm would search for a path from X to something in i, but in the third line of FINDMINSEP all nodes in i are removed, so there aren't any paths to i at all. I have tried both including and excluding i when this happens but couldn't get things to work. Currently I am excluding i, but in the failing test case this means that z is empty and so we fail to find a minimal m-separator, even though Z_1 is a valid minimal m-separator.

[jaron-lee]

Oh I think I figured it out, there is a missing line that should read:

"Remove from G' all nodes of I"

I should submit a PR on that paper...

[adam2392]

Oh I think I figured it out, there is a missing line that should read:

"Remove from G' all nodes of I"

I should submit a PR on that paper...

If it ends up working, we should document the "change" relative to what's in the paper, so at least our docstring is a pseudo-source of truth :p

[adam2392]

I'll do a more thorough check of the algo once we fix the nitpicks. Looking good!

[jaron-lee]

@adam2392 I think i basically fixed all the errors, but there is this one CI test failing. Doesn't look related to the code I've written. I vaguely recall we had this on another PR but I don't remember the fix.

[adam2392]

@adam2392 I think i basically fixed all the errors, but there is this one CI test failing. Doesn't look related to the code I've written. I vaguely recall we had this on another PR but I don't remember the fix.

Pushing a fix. The function just needs to be added to some autodoc (e.g. api.rst), so that way a rst page is generated for it, so then it can be auto-referenced by any corresponding

:func:`<func_name>`

[adam2392]

LGTM minus some doc fixes.

[adam2392]

https://output.circle-artifacts.com/output/job/622f3036-7e58-4476-9a6a-f9aa8cfa376c/artifacts/0/dev/api.html#networkx-experimental-functionality

[adam2392]

Will merge this once CIs give green light

[adam2392]

Thanks @jaron-lee !