Add an option for menu depth

Created a new patch/fork because the patch above doesn't seem to apply on the latest version.

Interdiff for patch #10 and patch #12

#12 works for me

This looks great, but I don't want to merge new functionality without tests.

nexusnovaz → changed the visibility of the branch 3032084-add-an-option to hidden.

I was trying to write some tests unfortunately I can't seem to get PhpStorm to work with it. I've rolled #12 into the MR !39. I'm going to keep trying to see if i can get mine to work, but if anyone gets it first, feel free.

tom konda → made their first commit to this issue’s fork.

I rebased feature branch and added a test for menu depth option.
But, need to fix SitemapUpdateSettingsTest::testUpdateHookN.

Putting on my maintainer hat, thank you, @nexusnovaz and @tom konda!

SitemapMenuTest::testMenuDepth() looks good to me: thank you very much!

Putting on my developer hat, I think that SitemapUpdateSettingsTest::testUpdateHookN() is failing because the new menu_depth configuration option needs to be added to the configuration schema in config/schema/sitemap.schema.yml — at time-of-writing, there is a schema for Menu plugins between lines 67 and 74 of that file.

I wanted to provide an example of what that configuration might look like, but I could not find an example, because this merge request uses the string unlimited to indicate unlimited menu depth...

1. I searched Drupal core and some contrib modules ( Admin Toolbar → , Better Exposed Filters → , Client-side Hierarchical Select → ) for the search term depth in all *.schema.yml files, to see there were any other examples of "depth" configuration that could either be a string or an integer, but I could not find any examples.
2. It seems like most "menu depth" configuration uses type: integer, where the integer 9 indicates the maximum possible depth.
3. This module's sitemap_plugin_settings.vocabulary schema defines both term_depth and rss_depth as type: integer, but use NULL to indicate unlimited depth (i.e.: by saying both type: integer and nullable: true in the config schema).
4. Other examples of "string or integer" configuration that I could think of (e.g.: system.performance:cache.page.max_age, automated_cron.settings:interval, dblog.settings:row_limit, system.file:temporary_maximum_age, etc.) use a special integer (0, -1) to indicate the string "Unlimited", "Never", "All", etc. That being said, I might have missed something!

In summary, it might be simpler to write a config schema if you changed the merge request to use an integer like -1, or the value NULL to indicate an unlimited depth, instead of what the merge request does now (i.e.: use the string unlimited to indicate an unlimited depth).

For what it's worth, I've found the Configuration Inspector module → to be helpful when writing and debugging configuration schemas.