Replacing jsonfield2 with jsonfield as former is merged back into latter one.

BOM-2447

refactor: Rename CourseEditLTIFieldsEnabledFlag to CourseAllowPIISharingInLTIFlag and use it for LTI1.3
This commit renames the CourseEditLTIFieldsEnabledFlag to CourseAllowPIISharingInLTIFlag since the aim is to expand its scope to all LTI-related PII sharing. It also removes the current LTI1.3 waffle flag for PII sharing.

This moves the CourseEditLTIFieldsEnabledFlag from edx-platform to this repo. This allows using the flag from both lms and studio.

* Revert "chore: Replace jsonfield2 with jsonfield"

This reverts commit 2fd330f8.

* fix: only kept jsonfield related revert changes and rest are removed

The difficulty here is that the empty string in an invalid JSON
dictionary (as opposed to None/NULL or '{}' which is just "blank");
attempts to instantiate models would fail, given the invalid data. This
meant we couldn't use the Django ORM to handle the migration entirely;
we need to craft some raw SQL to work-around these checks and
limitations.

Related-To: 42a9e342
Related-To: https://github.com/edx/xblock-lti-consumer/pull/144

The previous backfills handled NULL entries;
this handles empty strings.

The difficulty here was that since the empty string in an invalid UUID
(as opposed to None/NULL which is just "blank"), attempts to instantiate
models would fail, given the invalid data. This meant we couldn't use
the Django ORM to handle the migration entirely; we need to craft some
raw SQL to work-around these checks and limitations.

To correct the, in our case, single database entry that snuck in without
a UUID during the schema change.

Steps:
- Make the field editable
- Add `config_id` to all models missing it
- Make the field noneditable again

This implements the endpoint that LTI tools use to return the deep linking configuration to the LMS, along with the `ltiResourceLink` type to allow testing with demo tool.

Signed-off-by: Giovanni Cimolin da Silva <giovannicimolin@gmail.com>

A previous PR (#130) added a new unique field with a default value to the
LtiConfiguration model. Such cases need special handling in migraiton, however
the previous PR did not include that. This commit fixes the migration to include
the special handling for new unique fields.

otherwise this blows up, trying to migrate a record with no location
(the modulestore lookup throws).

Presumably this isn't (wasn't?) an issue in prod already, right?
But I did hit this in my devstack, having previously created an
LtiConfiguration record via Django Admin (without a location).

* Move LTI 1.3 Key management to model

This:
- Removes the need to load the modulestore on every public keyset endpoint call.
- Simplifies the block structure and parent method overrides.
- Removes private key, client id and related parameters from XBlock fields

It also includes a migration from the data stored in the block to the model.

* Cleanup unused test helpers

* Version bump

* Addressing review comments

* BD-24 Implement LTI AGS Score Publish Service and Results Service

* Address PR comments and add more validation

* Address PR comments

* Add tests; Fix error with scoreMaximum; Fix quality issues; Adjust user_id results url slightly

* Add permissions tests and address other PR comments

* Fix quality test

* Address PR comments

* Add initial version of LineItem Implementation

Signed-off-by: Giovanni Cimolin da Silva <giovannicimolin@gmail.com>

* Adding tests

* Add LTI tests and fix quality isses

* Quality nit

* Add missing requirement, upgrade

* Squash migrations

* Fix merge conflicts

* Addressing review comments

This change moves the LTI configuration retrieval to
a Django model that will LTI configuration.
The current model proxies back the to blocks to keep
backwards compatibility.

See reasoning for change at:
https://github.com/edx/xblock-lti-consumer/blob/master/docs/decisions/0001-lti-extensions-plugin.rst