Build: log usage of old output directory _build/html

[humitos]

We have changed the output directory from _build/html to $READTHEDOCS_OUTPUT/html in the last few weeks.

However, there are some projects that may have _build/html directory hardcoded in different places (e.g. conf.py). We want to log these projects and contact them to communicate this situation.

Ideally, we should show a warning in the build detail's page, but I don't think we currently have a way to display a warning message. We only support error messages in this page.

build_1     | [warning  ] Directory '_build/html' exists. This may lead to unexpected behavior. [readthedocs.telemetry.collectors] build_id=2756 builder=c9b06583941f commit=None ip=10.10.0.100 path_resolved=/usr/src/app/checkouts/readthedocs.org/user_builds/c9b06583941f/test-builds/checkouts/old-output-directory/.readthedocs.yaml project_slug=test-builds request_id=8bfcc743-dbc4-4886-8da0-b8a36709e556 task_id=ecbd1cd2-f352-43e0-be35-9442b1cab77e user_id=1 version_slug=old-output-directory

Related #10036

[agjohnson]

We should raise something user facing as well. I'm still a huge +1 on better error/warning patterns, but would it make sense to set the Build.error here? If there is something in this path, that almost certainly mean the build will be missing content if we don't fail the build explicitly.

[agjohnson]

We probably aren't as concerned about collecting this data as we are about saving user builds from having bad content. Anyone using doxygen and friends could have _build/html hardcoded, and will have silently broken docs.

[agjohnson]

We want to log these projects and contact them to communicate this situation.

It seems easier on us to just emit a build error. Is there a strong reason not to raise a build error instead?

[humitos]

@agjohnson the only reason was that I thought we didn't want to fail the build. I will update this PR (or close it and open a new one) to raise an error and clearly communicate this to the users.

[agjohnson]

Also, I'm not against logging this for our purposes either, that seems wise too. If we're really unsure how many builds might fail from this, that's perhaps a reason to add logging first. But it seems there probably aren't a lot of projects hitting this scenario, so I'm 👍 on jumping right to failing, and probably as soon as we can. If you think there are a lot of builds that will hit this, let's start with logging, but follow up very soon with build failures.

[humitos]

@agjohnson OK. I updated this PR so it goes out next week and we start collecting this data. I will open a new PR that fails the build completely in those cases, but we may not get in time to deploy it next week tho.