Undocumented attributes in all Starlark rules: expect_failure, transitive_configs, package_metadata

[tetromino]

The following attributes exist in all Starlark rules, but are not documented at https://bazel.build/reference/be/common-definitions#common-attributes despite not being marked as undocumented in the attribute's definition

• expect_failure - appears to be a moribund feature. Virtually nobody (afaict) is using it. Mark the attribute as undocumented and deprecate via a flag?
  • Note that this is the expect_failure natively-defined rule attribute - not the expect_failure macro parameter defined by skylib's analysistest.make() which uses the allow_analysis_failures mechanism instead.
• transitive_configs - appears to be a feature which was partially implemented but never got off the ground. A few things inside google are using it, but should they? Mark the attribute as undocumented and deprecate via flag?
• package_metadata - new attribute used by rules_license somehow? Probably needs to be properly documented in the build encyclopedia.

I noticed these while working on Stardoc support for symbolic macros that inherit attributes from rules. My current thought is to filter out expect_failure and transitive_configs from the user-visible doc output, and leave package_metadata in the list but undocumented (since it's not clear to me what it does).

CC @aiuto @gregestren @comius

[aiuto]

package_metadata allows you to attach pretty much any target label to another as an informational bit an aspect can query. It is the replacement name for applicable_licenses. It is documented at the package level.
But neither ever seems to have be documented as a common attribute.
Looking at history for src/main/java/com/google/devtools/build/docgen/templates/attributes/common I don't find it.
That is the right spot for common attributes, right?

[tetromino]

Looking at history for src/main/java/com/google/devtools/build/docgen/templates/attributes/common I don't find it. That is the right spot for common attributes, right?

Yes, that's the right place.

[aiuto]

Thanks. I'll create a PR to add a minimal doc.
Cooincidentally, I just wrote a longish description of how we use package_metadata to protect against code leaking to certain places. I guess I should sanitize that and do a blog post. That would provide more material for the description. Or, at least a place to link to that has a big example.