DOP-5816: Avoid parsing txt files in reserved directories

[rayangler]

Ticket

DOP-5816

Notes

Currently, the parser assumes that any txt file should be parsed as reStructuredText and be counted as a page. This PR makes it so that the code-examples directory is treated as a special directory name reserved for code examples, and not pages.

I created a staging link that did not result in any orphan page errors:

• Page that uses literalincludes and includes
• Page that is named "code-examples"
• rST source

This is the following behavior:

• Do not parse any txt file nested in any code-examples subdirectory as reStructuredText.
  • I checked if this affects any existing files using find . -type f \( -name "*.txt" \) -print0 | grep -z "code-examples" | xargs -0 -I {} realpath {} across the subdirectories I had locally, and it shouldn't (unless my content repos were severely out-of-date).
  • I also confirmed with Dachary that we should apply this change to any txt file in any code-examples subdirectory, regardless of nesting level.
• Parse any rst file nested in any code-examples subdirectory as reStructuredText.
  • This is to provide backwards compatibility with any docs sites that currently use code-examples with rst files, such as server manual.
• Parse any txt file that is called code-examples.txt (unless it’s nested in some code-examples subdirectory).
  • This is specifically for this meta page

README updates

• • This PR introduces changes that should be reflected in the README.md and/or HACKING.md, and I have made those updates.
• • This PR does not introduce changes that should be reflected in the README.md and/or HACKING.md

[seungpark]

LGTM 👍 thanks for the insightful test!

[dacharyc]

Awesome - looks like this captures the behavior we want. Thank you for investigating the related cases! LGTM 🚢

[zdw001]

Not a huge deal because eventually the parser will be going away, but I would have loved for this to have been defined by the user (let's say in snooty.toml). Things like this can make the platform more "brittle"

[rayangler]

I agree. I made this a set to begin with to allow for that flexibility if needed. The reason why it wasn't implemented here was for convenience and consistency since this seems like desired behavior across all docs sites. If this assumption is or becomes false, I'd recommend creating a follow-up to this accordingly.