feat: generic sidebar notification plugin

[zacharis278]

This is just a POC to prove out the API of params we're passing I didn't touch the new sidebar or write any tests.

Removes upgrade component specific properties from sidebar/notification plugin slots.

Since we're merging into the feature branch this would be the resulting diff against main: master...zhancock/generic-notification-plugin

Risks/Concerns
This component is still highly coupled with the state of the learning MFE that detail is just hidden into the component now. If the redux store changes structure it could break our plugin. Once this is working it would be good to evaluate the component code we've copied over, there's probably a lot of conditions we can carve out if the upgrade component is 2U specific.

Pairs with https://github.com/edx/frontend-plugin-advertisements/pull/10
^^ in case this isn't publicly visible the approach is to useModel and get all of these fields rather than passing them over a pluggable API.

eg

  const {
    accessExpiration,
    marketingUrl,
    offer,
    timeOffsetMillis,
  } = useModel('coursewareMeta', courseId);

[zacharis278]

revert back to what's in main today, no change in behavior if the plugin is off.

[zacharis278]

This drives the 'red dot' notification icon. I've removed the 'upgrade' from how this is passed to the plugin to keep it general. On the learning MFE side all the variables relating to this are still called 'upgrade...' we should rename all of that eventually. Probably at the same time we remove all the upgrade code from the learning MFE.

I think these would belong on the API for this plugin slot since any plugin here may want to drive that icon. That said, the code for the red dot is tightly coupled to upgrade right now but you could use it creatively for other purposes. It would probably take further consideration on how we handle notifications from multiple sources (if you put more than 1 plugin here) when the need arises. My thinking is the existence of a getter/setter wouldn't need to change so what I have here should be a stable interface.

[arbrandes]

the approach is to useModel and get all of these fields rather than passing them over a pluggable API.

For better or worse, I think that will be inevitable in some of the first cases (like this one). This will still help guide how to build out an API that we can consider stable, though.

[zacharis278]

I had to modify how this works a bit because we get react errors if testId is passed to the PluginSlot component. We can only pass id, pluginProps, and children. I opted to use id instead here since that would be required to have a functional plugin slot.

[zacharis278]

for this and other components I split testing the plugin slot and behavior of the default content w/o a plugin since we expect the latter to be removed.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.27%. Comparing base (1e29715) to head (eba6583).

Additional details and impacted files

@@                      Coverage Diff                      @@
##           feat/upgrade-plugin-slots    #1379      +/-   ##
=============================================================
- Coverage                      88.30%   88.27%   -0.03%     
=============================================================
  Files                            293      293              
  Lines                           5009     5008       -1     
  Branches                        1267     1237      -30     
=============================================================
- Hits                            4423     4421       -2     
- Misses                           570      571       +1     
  Partials                          16       16              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zacharis278]

changed the name on these to align convention with existing plugins xxxxx_plugin

[varshamenon4]

lgtm!