Cleaning up docs-related stuff

[pedro-psb]

The new process of building docs is quite different from the one we had before, and there are some things that doesnt make sense to be kept in the plugin-template machinery anymore:

ci_update_docs

On a rough perspective, this option was useful before because each plugin docs was more independent.
Now the control of the docs process is centralized in the pulp-docs tool, plus we don't worry about building docs for older branches anymore. AFAIK, all the old machinery is already deactivated and I can't think of a reason to keep it.

If that sounds good, we should:

• remove template/docs
• add a deprecation notice to --docs and make it no-ops
• clean-up related code

docs_test

Similarly, this made sense with independent docs, but that's unsafe in the current centralized approach.
If one repo decides to disable docs testing, all plugin CI are in the risk of failing if this one plugin merges something that will break the unified docs build.

This is to say that, if a plugin is part of the unified docs, it must test the docs.

Alternative for not testing docs

If the plugin doesnt want to be part of the unified-docs, it can "unsubcribe" via a PR to remove itself from the participants list.
Currently, the docs-participant list lives in pulp-docs (here).

This handling of the subscription can be improved, but it would already work as it is.

An improvement idea I had is to keep such a list of participants here in plugin_template, so its more convenient to match with docs testing workflows: a plugin will only have docs workflow if it's in the list, and pulp-docs will only use that plugin if it's in that list. It wouldn't be a problem for pulp-docs to have to fetch that list from here, as its by nature an aggregation tool.

[mdellweg]

That all sounds good to me.
And I'd say "What if a plugin not managed by us wants to have other means of docs?" is something that can be handled at their end.