fix: ignore dates set in studio edit modal when non-manual date config is set

[jansenk]

TL;DR - Ignore validation of datetime fields when non-manual datetime config is specified

JIRA: AU-1448

What changed?

• When you select a date config on the ORA edit dialog that is non-manual, the manual datetime controls are hidden, but still validated. A complicating detail is that they do need some sort of value send to the backend, since we're expecting non-null values, and I thought that change would be very far reaching and annoying.
• What I did was, 1) the basic "ignore the validation when we aren't using the fields" but then 2) what to send to the backend as "dummy" values that will pass backend validation and own't make us rewire all of how dates are handled? I figured since our backend uses '2001-01-01' as a default start and '2099-12-31' as a default end, that was a reasonable default.
• I didn't want the values to be completely blown away, though. If someone spent the time to manually set all of the dates, and then accidentally clicked one of the other options, I didn't want the values to all be reset to defaults, so I added a feature to the DatetimeControls we are using to be able to "stash" and "pop" a value.
• When we select a non-manual option, the DatetimeControls stash their current user-defined values in memory and set their "real" values to the default start/end. If we then go back to manual datetimeconfig, the user defined values are put back where they were.

There are also other things that were changed here! I had a lot of issues with locally testing the js files, specifically that the ChromeHeadless browser would hang and be unreachable. By un-headless-ing the browser, I found that the ChromeHeadless was getting stuck on the chrome "log in to a profile" page (which is currently not possible to disable due to 2u controls). This isn't a problem on the CI/CD or for non-2u devs, but for us 2uites i added a firefox browser to the dev requirements and added config to karma.conf.js to use it as a test runner.

Developer Checklist

• Reviewed the release process
• Translations and JS/SASS compiled
• Bumped version number in openassessment/__init__.py and package.json

Testing Instructions

• On the main branch, create an ORA with just a staff step, in a subsection with a due date.
• Click Edit, and add a peer and self step (and the config for those steps)
• Go to the schedule tab and verify that the self and peer dates were created as blank inputs. Just for testing's sake, clear out the submission deadlines, too.
• Change the date config to subsection due date. The inputs should disappear and you should see the message about subsection due dates.
• Click save. You should get an error about problems with the schedules tab.
• (If you want, you could also repeat this but instead of blank, use invalid dates, like setting the peer due date before the submission start date.)

switch to this branch

• Go back to that ORA. edit. You'll have to re-add the steps because they wouldn't save.
• Repeat the nonsense above, but this time you should be able to save correctly.
• Also verify that anything you enter in for manual will be persisted once you swap back to it.

Reviewer Checklist

Collectively, these should be completed by reviewers of this PR:

• I've done a visual code review
• I've tested the new functionality

FYI: @openedx/content-aurora

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.29%. Comparing base (b5d96f3) to head (71039a9).
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2229   +/-   ##
=======================================
  Coverage   95.29%   95.29%           
=======================================
  Files         195      195           
  Lines       21624    21624           
  Branches     1502     1502           
=======================================
  Hits        20606    20606           
  Misses        771      771           
  Partials      247      247           

Flag	Coverage Δ
unittests	95.29% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[hajorg]

LGTM