DISCO-3202 - Enrich the curated-recommendations endpoint with icon-urls

[gruberb]

References

JIRA:

• DISCO-3204
• DISCO-3204
• DISCO-3204

Description

Enriching the /curated-recommendations endpoint with a iconUrl field for each article recommendation. The iconUrl is a HttpUrl, taken from the Manifest provider, and if the favicon for the domain is available, we attach it to a recommendation. Otherwise, we return an empty string.

In the background, the Manifest is updated once a week, and therefore the icons will be updated in this interval. Which means newly added domains to the Manifest will be available to this endpoint at that time.

PR Review Checklist

Put an x in the boxes that apply

• This PR conforms to the Contribution Guidelines
• The PR title starts with the JIRA issue reference, format example [DISCO-####], and has the same title (if applicable)
• [load test: (abort|skip|warn)] keywords are applied to the last commit message (if applicable)
• Documentation has been updated (if applicable)
• Functional and performance test coverage has been expanded and maintained (if applicable)

[Herraj]

🖼️

[ncloudioj]

LGTM, let's confirm a few things before the merge.

• Since this would add a new filed to the recommendation endpoint, let's confirm that the API consumer(s) are ready to consume (or ignore) it without affecting anything there. I think @mmiermans should be a blocking reviewer for this patch.
• The icon lookup is tied to the image manifest which in turn is subject to future updates with the manifest, meaning that the icon could appear / disappear over time. We need to confirm if that's an acceptable behavior for the consumer as it'll affect the user experience in the browser. If certain icons should always be present, then we need to de-couple those from the manifest and use other ways to fulfill the icon requests (e.g. allow to "pin" certain icons in the manifest provider).
• Lastly, this establishes direct dependence between the curation recommendation provider and the manifest provider, meaning that the latter must be initialized sooner than the former, otherwise, icons might not be available. Coincidentally, the manifest provider gets initialized prior to the recommendation provider, but since they both rely on the cron jobs to download data in the background, it's not guaranteed that order. We also need to confirm that is OK for the consumer.

[mmiermans]

Only have some questions related to testing. The rest looks good. Thanks for making this change! 👍

[mmiermans]

Since this would add a new filed to the recommendation endpoint, let's confirm that the API consumer(s) are ready to consume (or ignore) it without affecting anything there. I think @mmiermans should be a blocking reviewer for this patch.

We set the expectation that adding attributes is not a breaking change, but that clients (Desktop and Android for now) will be notified of any changes regardless, to avoid surprises. If they're not already aware, could you send them a Slack message before merging this?

[mmiermans]

Suggested change

	def setup_suggest_providers(corpus_provider):
	def setup_curated_recommendations_provider(corpus_provider):