chore: Add Markdownlint checking and CI

[nschonni]

Why:

Linting the markdown will ensure that common rendering issues are caught and that the files are consistently formatted.

What's being changed:

• Add a markdownlit config with all the current rules that are failing turned off
• Add a CI job to run whenever markdownfiles or the config are changed
• Update the nested code fences inside ordered list that had incorrect indenting. I would have skipped that to later, but it was crashing the parser
• Updated the translation files for the same reason in a separate commit, but they could be undone and ignored
• Probably easier to review with the "Hide whitespace changes" first, before looking at the rich-diffs

Check off the following:

• All of the tests are passing.
• I have reviewed my changes in staging.
• For content changes, I have reviewed the localization checklist
• For content changes, I have reviewed the Content style guide for GitHub Docs.

[welcome]

Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[nschonni]

@chiedo I noticed you changed all the action version to shas. Is that something that I need to do, or would that happen if this is accepted afterwards?

[chiedo]

👋🏿 @nschonni thanks for this PR! Yes the sha changes will automatically apply. They should be present once you click the "Update branch" button.

We're running a little behind on things but we'll review this soon!

[nschonni]

@chiedo no worries, I see you have a bunch of hacktoberfest spam to deal with right now 😆

I hit the update, but since this is proposing a new Action file, I figured it might need some manual intervention

[chiedo]

Got it! We'll take a look.

[nschonni]

@chiedo aha, figured it out based on the CI failure. I copied the values from the pa11y.yml

[nschonni]

Rebased. If reviewing with the whitespace diff off, I commented on the only text change on the English doc that required changes in the translated docs because the table format issue there got mangled in the translation parser

[chiedo]

@rachmari / @janiceilene would you be willing to take this one over? This would impact the writers much more heavily than engineering.

From an engineering perspective, the change I would suggest is that the translations directory is exempt from the linter. Because everything in that directory comes from Crowdin.

[nschonni]

@chiedo I can ignore the translations folder, or setup a separate job that you could ignore if it's failing, but I have seen Crowdin mangle formatting sometimes. EX: the tables in this PR when it misparsed the orignal english version

[chiedo]

Thanks @nschonni ! I understand why you'd suggest that. But changes in the translations directory gets overridden regularly by a service called Crowdin. So anything issues we fixed would return with the next sync.

[nschonni]

@chiedo yup, I get not wanting to take PRs directly on the content because Crowdin overwrites this (I was involved in setting it up for Node.js), but checking the content coming from Crowdin makes sure the content isn't malformed when it comes back from there.

The original parsing issue that made me need to modify the MD files in this PR has been fixed upstream, so if a release comes out there soon, I'll pull out those content changes to a new PR.

I'm thinking that this should be split into 2 jobs with 2 different path filters to handle the translations separately though. That way the second translations-only job could fail/be ignored while the translations are addressed in Crowdin, and not show a failure on other MD changes

[nschonni]

@chiedo OK, split the job so there is different filtering based off of the translated vs. regular content. This way you can catch if Crowdin pushes broken markdown, but those failures won't show up on PRs for non-translated content

[nschonni]

I can also rebase out the translated file changes, but the second job will crash till they are addressed

[chiedo]

Got it thanks! We'll wait and see what @janiceilene and the writers think. This one will be their call as it would affect their workflows.