initial graph properties API support

[nsajko]

motivation, for the PR and for the new package, to be added soon

EDIT: putting this on hold, may still need to think about the design of GraphProperties.jl

[nsajko]

This can not be merged until the GraphProperties.jl package is registered. If the design looks OK I will start the registration process for GraphProperties.jl eventually.

[Krastanov]

Julia Formatter in the tests uses v1 (check the project.toml in tests). We have not converted to v2 yet.

[Krastanov]

To me it seems like an interesting proposition, but I suspect it will take a while to get the input of all stake holders. I am more of a caretaker of the package, as a lot of the people that actually built the package are not active maintainers anymore, so I would like to be slow and methodical in gathering feedback on this change. While it is not breaking in any way, and it seems well thought out, going in this direction will be a significant future API commitment.

Here are initial questions that will pop up in the discussion about this (addressing some of them early on will probably save us some time when we start gathering feedback on various forums):

• There were many earlier attempts at polishing and better structuring the Graphs.jl API, e.g. https://github.com/JuliaGraphs/GraphsBase.jl -- are there any earlier discussions (e.g. in the issue tracker of GraphsBase.jl) that relate to this work here and should inform how we deal with it
• Some places of Graphs.jl already uses SimpleTraits.jl -- should we instead rely on SimpleTraits instead of adding yet another abstraction here with yet another new dependency.
• Why is this is a better choice than the already existing setup? What problems are being solved with it, and how do other parts of the Julia ecosystem solve similar problems? Focusing in particular on the possibility of a simpler solution, as added rules and complexity can be an impediment to new contributions if the benefit from the rules and complexity are low. Most people would not be sympathetic to a change that is merely organizational/architectural unless it is shown that the new more complicated rules about how to organize things do not lead to simplicity and ease of implementation in the future. This is especially true for Graphs.jl which does not have significant volunteer maintenance force right now.
• (added in edit) How should this interact with the GraphsInterfaceChecker.jl

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.64%. Comparing base (09f48ea) to head (1e14024).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #464      +/-   ##
==========================================
+ Coverage   97.38%   97.64%   +0.25%     
==========================================
  Files         120      118       -2     
  Lines        7004     6918      -86     
==========================================
- Hits         6821     6755      -66     
+ Misses        183      163      -20     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gdalle]

Just popping by to say that adding a new dependency to Graphs, especially one registered so recently, is bound to raise some eyebrows, especially without justification. As Stefan pointed out, there have been many many redesign discussions which eventually led nowhere for lack of dev time, so I like his conservative approach to caretaking for the time being.