feat: accept library_content_key on the v1 Xblock create payload (FC-0118)

[taimoor-ahmed-1]

Description

The v1 XblockViewSet (cms/djangoapps/contentstore/rest_api/v1/views/xblock.py)
gates every write behind @validate_request_with_serializer, which validates the
request body against XblockSerializer. That serializer subclasses
StrictSerializer, so any top-level field not declared on the serializer causes
a 400 before the handler runs.

Studio's real block-creation payload includes library_content_key when a
course block is created by importing a component from a v2 library. The create
handler already reads it:

# cms/djangoapps/contentstore/xblock_storage_handlers/view_handlers.py
if upstream_ref := request.json.get("library_content_key"):
    # ... import the component from the v2 library

But because library_content_key was not declared on XblockSerializer, the
strict serializer rejects that payload with a 400 before the handler is reached.
This makes the v1 create endpoint unusable for the (common) library-import path.

This PR declares library_content_key as an optional field on XblockSerializer
so the strict validation accepts the legitimate create payload.

Why this matters now

This unblocks migrating frontend-app-authoring's block-creation caller
(createCourseXblock) from the legacy /xblock/ route to the standardized
/api/contentstore/v1/xblock/ endpoint as part of the FC-0118 downstream-consumer
migration — see openedx/frontend-app-authoring#3127 (item #1, Xblock). Without
this field, migrating "add/import block" to v1 would break block creation.

Changes

• cms/djangoapps/contentstore/rest_api/v0/serializers/xblock.py — declare
  library_content_key = serializers.CharField(required=False, allow_null=True).
• cms/djangoapps/contentstore/rest_api/v1/views/tests/test_xblock_viewset.py —
  regression test asserting a create body carrying library_content_key reaches
  create_xblock_response (200) instead of being rejected (400).

Testing

• Added XblockViewSetRoutingTest.test_create_accepts_library_content_key.
• Run: pytest cms/djangoapps/contentstore/rest_api/v1/views/tests/test_xblock_viewset.py.

Notes

• Base branch: feat/axim-api_improvements (the FC-0118 standardization
  feature branch where the v1 XblockViewSet lives; not yet on master).
• The field is optional and additive — it does not change any existing behaviour;
  it only stops the strict serializer from rejecting a field the create handler
  already consumes.
• Two other fields the legacy caller sends (type, courseKey) are not added
  here because they are redundant/ignored by the handler; the frontend migration
  PR drops them instead of sending dead data.

[openedx-webhooks]

Thanks for the pull request, @taimoor-ahmed-1!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

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.

Details

---

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.