feat: make staged static asset size limit configurable by site.

[anfbermudezme]

Description

This PR makes the static asset size limit used by content staging configurable through Site Configuration.

Today, static assets larger than 10 MB are not copied into staged content. Instead, the staged file record is still created with metadata such as source_key_str and md5_hash, but without storing the actual data_file. This behavior is useful because staged files may be stored remotely, and uploading large assets can be slow or unnecessary when the asset can still be resolved from the source contentstore.

This change preserves the existing 10 MB default, while allowing operators to override the threshold per site using:

{
  "CONTENT_STAGING_STATIC_ASSET_SIZE_LIMIT_BYTES": 52428800
}

The value is expressed in bytes. For example, 52428800 sets the limit to 50 MB.

Behavior

• If CONTENT_STAGING_STATIC_ASSET_SIZE_LIMIT_BYTES is not configured, the existing 10 MB limit is used.
• If the configured value is valid, that value is used as the maximum staged asset size.
• If the configured value is invalid, the code logs a warning and falls back to the default 10 MB limit.
• Assets larger than the configured limit continue to preserve their metadata, but omit data_file, matching the current recovery/import behavior.

Motivation

Some deployments need to support larger static assets during content staging workflows, especially when copying or syncing content that includes larger media or supporting files.

Making the limit configurable through Site Configuration keeps the default behavior unchanged for existing installations, while allowing operators to opt in to a higher or lower threshold without requiring a code change.

Scope

This PR intentionally keeps the change minimal:

• Adds a Site Configuration lookup for the staged static asset size limit.
• Preserves the existing 10 MB default.
• Keeps the current oversized-asset metadata behavior.
• Adds fallback handling for invalid configuration values.
• Updates the inline comments to describe the configurable behavior.

Testing Notes

• Verified that the default limit remains 10 MB when no Site Configuration value is present.
• Verified that a custom CONTENT_STAGING_STATIC_ASSET_SIZE_LIMIT_BYTES value changes the threshold used when staging static assets.
• Verified that invalid Site Configuration values fall back to the default 10 MB limit.
• Verified that oversized assets still create staged metadata while omitting data_file.

[openedx-webhooks]

Thanks for the pull request, @anfbermudezme!

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.