feat: decouple xblock and lti config to fix copy-paste

[navinkarkera]

Description:

Decouples config ID and xblock usage_key such that the same configuration can be used by more than one xblock.

• We add a new table that links xblock to a specific lti configuration object in database.
• Create a migration that generates entries in this new table based on existing lti configurations.
• Add config_id field to LTI xblock so that copy-paste works, when a lti xblock with config id is pasted it just creates a new link entry in the new table pointing to the existing lti configuration.
• Limitation: This method only works in the same instance, so importing and exporting the course in new instance that doesn't have the related lti configuration already in place will not work.
• This PR also adds signal handlers to handle delete or duplicate events related to lti xblocks. These handlers delete unlinked configuration objects and remove linked entries of deleted xblocks.
• Create a migration script that removes location and direct links to LTI configuration from different tables.

Related to: #594

Concerns:

We need to extensively test this PR with all LTI features including proctoring, deep linking, scoring etc. The existing architecture tightly couples config_id and location, and this resulted in urls with config_id that only link to a single xblock, however this PR decouples config_id and xblocks resulting in multiple xblocks being related to a single config_id. I have tried to narrow down to single xblock using resource_link_id wherever possible but defaulted to first instance of link entry in cases where it is not possible (In theory this should work as the linked configuration will be correct in any case).

Questions/Suggestions:

• What should happen when author starts editing pasted/duplicated xblock settings? Specifically Configuration Type field, as this change should be same in database as well as xblock to make sure that it works properly.
  Problem: We cannot update the configuration in database as it is shared between original and the copy.
  Possible solution: When the author changes config_type, we create a new configuration entry for this xblock with a new config_id.

Test instructions:

• I have created a sandbox PR: DO NOT MERGE: only needed for sandbox openedx-platform#38144 with latest changes.
• This page contains all details required to login into the sandbox.
• Test all LTI related features there.

[openedx-webhooks]

Thanks for the pull request, @navinkarkera!

This repository is currently maintained by @Faraz32123.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

🔘 Update the status of your PR

Your PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate.

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[navinkarkera]

@feanil @rpenido @Faraz32123 This is not completely ready yet but I want you guys to be aware of these changes. Kindly go through the description and the changes and let me know your thoughts.

@ayub02 Please find the instructions and sandbox details in the description. Please try and test all LTI features and let me know if you face any difficulties.

[rpenido]

Hi @navinkarkera! Thank you for the PR!

I did a quick check through the code, and it is looking good, but I have one doubt:
Did you consider removing the LTIConfig model and migrating the data directly to the XBlock? We would lose the "reusability" we have here in favor of simpler code that should work fine with copy/paste/export (even for other instances). And in the near future, we can build something like LTIStore with permissions and a friendly UI on top. That would be a big regression? Would we lose some use cases we have today?

[navinkarkera]

@rpenido There are some problems that I can think of with that approach:

• The urls currently have config_id which is used to fetch the configuration objects. Example: https://pr-38144-885846.axim-sandboxes.opencraft.hosting/api/lti_consumer/v1/token/102e736f-cf9d-4836-a315-900a45bb73b1.
  • The UUID at the end is used by the platform to get configuration.
  • If we remove the table, we'll need to fetch the xblock based on the config_id field and then use it. I think it is not very efficient to do so. (But I might be wrong though).
  • Before config_id was introduced, usage_key was used in the URLs, so if a author copies and pastes such a block it will always point to the original block and ignore the copied block configuration. (We have same issue here, but the linked configuration object is same).

We can probably overcome above issues but it will take a lot more time to implement. However another problem is that the decoupling of LTI config and xblock was done to allow launching LTI outside of xblock context, see https://github.com/openedx/xblock-lti-consumer/blob/master/docs/decisions/0007-lti-launch-decoupling.rst. So removing LTI config table would undo the decision.