Prevents reapplication of errored or disallowed changes and resolves issues handling M of N and learner_managed values

[bjester]

Summary

Description of the change(s) you made

• Corrects defensive behavior on handling M of N values, arising when adding a new exercise
• Prevents overwriting of M or N values when user changes one of them, requiring multiple edits from the user
• Allows learner_managed to be null so that the field is deleted in the serializer
• Fixes undocumented issue where errored or disallowed changes would be reapplied during fetch

Manual verification steps performed

1. Manually remove the allow_null=True change to the learner_managed field
2. Start or restart the celery workers
3. Create a new exercise and set invalid M of N values
4. Observe you should receive errors for the change since it should also set learner_managed to null
5. Edit the exercise again and apply valid M of N values distinctly different than last time
6. Click Finish
7. Edit the exercise again, observe the M of N values shouldn't have changed
8. Reapply the allow_null=True change to the learner_managed field
9. Restart the celery workers
10. Edit the exercise and set invalid M of N values
11. Observe the change should no longer error (although the resource should be incomplete and show a validation error)
12. Edit the exercise again and apply valid M of N values distinctly different than last time
13. Click Finish
14. Edit the exercise again and observe the values are consistent
15. Switch the goal to '100% correct' and then back to 'M of N'
16. Observe your M of N values were preserved

References

Fixes #3758
Fixes #3757

Comments

I originally split out #3757 into another issue #3758 but ended up fixing both here

---

Contributor's Checklist

PR process:

• If this is an important user-facing change, PR or related issue the CHANGELOG label been added to this PR. Note: items with this label will be added to the CHANGELOG at a later time
• If this includes an internal dependency change, a link to the diff is provided
• The docs label has been added if this introduces a change that needs to be updated in the user docs?
• If any Python requirements have changed, the updated requirements.txt files also included in this PR
• Opportunities for using Google Analytics here are noted
• Migrations are safe for a large db

Studio-specifc:

• All user-facing strings are translated properly
• The notranslate class been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. icons, user-generated text)
• All UI components are LTR and RTL compliant
• Views are organized into pages, components, and layouts directories as described in the docs
• Users' storage used is recalculated properly on any changes to main tree files
• If there new ways this uses user data that needs to be factored into our Privacy Policy, it has been noted.

Testing:

• Code is clean and well-commented
• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Any new interactions have been added to the QA Sheet
• Critical and brittle code paths are covered by unit tests

---

Reviewer's Checklist

This section is for reviewers to fill out.

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[rtibbles]

Steps 14-16 did not pass manual testing - but as they seem to not be required for either of the issues being closed here, nor critical behaviour, we can let this go.