Rename the ContentProvider model to ContentSource

[krysal]

Problem

In #4238, a confusing situation was raised when we found that the items of the ContentProvider model actually correspond to sources, not providers. We want to correct this naming so the usage of this model is clear and safe.

Description

Here I copy @obulat's comment explaning the situation:

Originally, we only had source. Then, the provider field was added to denote the provider of the metadata about the image ¹. The PR that added the provider field, didn't touch the ContentProvider model, and this model wasn't updated later.

ContentProvider currently only handles sources, not providers. You can check this if you go to https://openverse.org/sources - you'll see NASA in the table. This uses the stats endpoint that queries sources, not providers.

All this is to say that I think we can proceed with this PR, and exactly because we rely on ContentProvider to filter sources. I'll review the code again to check that this is true.

...

Could we open a new issue (maybe even a Project proposal request?) to

• Rename the ContentProvider model to ContentSource
• Create a new ContentProvider model for providers
• surface provider stats in the API
• use this view to add provider links to the frontend single result page
  There is some additional info in the cc-archive issues and PRs (https://github.com/cc-archive/cccatalog-api/pull/548/files#r444933371, Expose provider field cc-archive/cccatalog-api#560 (comment))

By the way, some of the issues mention that a source can appear in several providers. I think we have a project for implementing this, this would reduce the number of duplicates we have, but we would need to find a way to handle a work that has several providers.

Footnotes

1. https://github.com/cc-archive/cccatalog-api/issues/531 ↩

[sarayourfriend]

We need to rename the serializer, fix the documentation, and update variable names as well. The model name is not the only place that has this issue. I've discussed that in this comment: #4238 (comment)

I'd also recommend we only change the API-level code, rather than going through the hassle of updating the table name at this time. Doing just the model and code level changes makes this a much easier and less tedious change to implement than if we also included changing the table name.