feat: Add support for showing and hiding parts of the progress page

[xitij2000]

No description provided.

[Agrendalath]

@xitij2000, please see the following recording. We cannot have this kind of delay when hiding the elements on the page:
Screencast_20241008_182416.webm

I just noticed that there is already a model with a per-course Progress page configuration that's used by the Course Home API. If we would need to add artificial delays to rendering the interface until the Course Blocks API gives us the response, maybe extending this configuration would actually be better?

Also, a note about the Pages & Resources - the options should either:

1. Default to True.
2. Be "Hide the component" instead of "Show the component".

Otherwise, visiting the "Configure progress" modal and pressing "Save" changes the Progress page configuration, which is confusing.

[xitij2000]

@Agrendalath Sure, I think it makes sense to hide by default. I did intend in the code to default an undefined value to true, but I guess that didn't work? The logic should be to hide till the value is known, but have an undefined value equate to true so that if this isn't configured, then the component is shown by default.

The issue isn't with extending that configuration, it's with extending it in a way that is upstream-friendly. Making a change to an existing model is asking for trouble during upgrades when we need to cherrypick migrations etc.

If upstream is okay with having this feature, then we can move this to the man course structure and return it with the existing API.

[Agrendalath]

@xitij2000,

Sure, I think it makes sense to hide by default. I did intend in the code to default an undefined value to true, but I guess that didn't work? The logic should be to hide till the value is known, but have an undefined value equate to true so that if this isn't configured, then the component is shown by default.

What are the next steps here?

The issue isn't with extending that configuration, it's with extending it in a way that is upstream-friendly. Making a change to an existing model is asking for trouble during upgrades when we need to cherrypick migrations etc.

If needed, we can backport this change only for this client and handle it during the upgrade. It won't be upstream-unfriendly this way.