Clean up and update metadata files for IIS, MSSQL, and MySQL/MariaDB.

[igorpeshansky]

Description

Bring the third-party metadata.yaml files for IIS, MSSQL, and MySQL/MariaDB up-to-date with the public docs, in preparation for eventually using them as the source of truth.

A follow-on to #1772.

Related issue

b/240700717
b/356682372

How has this been tested?

All of the metadata.yaml changes have been run through an automatic doc generator and compared with the existing documentation. The added third-party application tests have passed.

Checklist:

• Unit tests
  • Unit tests do not apply.
  • Unit tests have been added/modified and passed for this PR.
• Integration tests
  • Integration tests do not apply.
  • Integration tests have been added/modified and passed for this PR.
• Documentation
  • This PR introduces no user visible changes.
  • This PR introduces user visible changes and the corresponding documentation change has been made.
• Minor version bump
  • This PR introduces no new features.
  • This PR introduces new features, and there is a separate PR to bump the minor version since the last release already.
  • This PR bumps the version.

[mtabasko]

The doc-related files look fine to me.

[jefferbrecht]

Now that we have separate folders for v1 and v2, does it make sense to update the v2 enable scripts (IIS, MSSQL) so that they only test v2 rather than v1+v2 simultaneously?

[igorpeshansky]

Now that we have separate folders for v1 and v2, does it make sense to update the v2 enable scripts (IIS, MSSQL) so that they only test v2 rather than v1+v2 simultaneously?

Do you mean putting the iis/mssql v2 receivers into the default_pipeline?

[jefferbrecht]

Now that we have separate folders for v1 and v2, does it make sense to update the v2 enable scripts (IIS, MSSQL) so that they only test v2 rather than v1+v2 simultaneously?

Do you mean putting the iis/mssql v2 receivers into the default_pipeline?

Sure, either that or overwriting the built-in iis/mssql receivers.

[igorpeshansky]

Now that we have separate folders for v1 and v2, does it make sense to update the v2 enable scripts (IIS, MSSQL) so that they only test v2 rather than v1+v2 simultaneously?

Do you mean putting the iis/mssql v2 receivers into the default_pipeline?

Sure, either that or overwriting the built-in iis/mssql receivers.

Right, putting them in the default_pipeline is exactly the way to override the built-in ones. I don't think it's a good idea, because those enable files are also used as example configurations in the docs, and we don't necessarily want to encourage users to override the built-in receivers. The default receivers are harmless, in that they only add a few metrics that we (now) don't even check, so I'd just leave them alone.