feat!: Collection.key -> Collection.collection_code

[kdmccormick]

Description

Also, standardize internal usage of collection_key to collection_code.
This helps clarify that Collection.key is not an OpaqueKey, but is rather
a local slug, which can be combined with other identifiers to form a fully-
qualified LibraryCollectionKey instance.

Backup now writes both 'key' and 'collection_code' to collection TOML files,
so older software (which only knows 'key') can still read new archives.
Restore accepts either field, preferring 'collection_code' and falling back
to the legacy 'key'.

BREAKING CHANGE: Collection.key has been renamed to Collection.collection_code,
and Collection.objects.get_by_key is now Collection.objects.get_by_code.

BREAKING CHANGE: Collection.collection_code now validates that its contents
matches '[A-Za-z0-9-_.]+'. This was already effectively true, because
LibraryCollectionKey can only be built with slug-like parts, but we now
we explicitly raise ValiationError from create_collection.

Supporting info

This follows the naming convention proposed in: openedx/openedx-proposals#773

Part of: #322

Related openedx-platform PR: openedx/openedx-platform#38214

Testing

Things that work without any openedx-platform changes:

• The Collections tab renders in a library

• Django admin looks good:

  

• Running Backup yields both key and collection_code

  [collection]
  title = "Axim A1_1"
  key = "axim-a1-1"
  collection_code = "axim-a1-1"
  description = "This collection contains content migrated from a legacy library on: Dec 18, 2025 at 19:04"
  created = 2025-12-18T19:04:59.952807Z
  entities = [
      "xblock.v1:html:a1-c",
      "xblock.v1:html:a2-c_1",
     "xblock.v1:video:video",
  ]
  

Things I'll test once I have the openedx-platform PR ready:

• Restore
• Adding and managing collections

AI disclosure

I used Claude Code to write:

• the backup-restore changes which ensure that both collection_code and key are supported, and its unit test
• the unit test to make sure that non-code characters in a collection_code raise a ValidationError

I reviewed all of that code carefully.

[kdmccormick]

I've never seen subTest before--I'd have used ddt myself--but Claude generated it and I think I like it. Reviewers, let me know if you disagree.

[bradenmacdonald]

I am trying to use @pytest.mark.parametrize instead of ddt, because ddt has no types and is not really maintained. But @pytest.mark.parametrize doesn't work on UnitTest class methods, so this seems like a nice alternative :)

[kdmccormick]

@ormsbee , @bradenmacdonald , could one of you review when you have a chance?

I won't merge until Braden's Containers change is released, as to not complicate that.

[kdmccormick]

@ormsbee @bradenmacdonald , this is ready. Curious if you'd prefer Collection.code or Collection.collection_code. I'm learning towards the former (in spite of the current state of this PR) but it's not a strongly help opinion. Whatever we choose, I'll just want to be consistent going forward for container_code, component_code, etc.

[kdmccormick]

@ormsbee @bradenmacdonald I think I should let the OEP land before merging this or any opaque-key changes. I'll return this to draft, feel free to unsubscribe and not review for the time being. I'll probably queue more of the changes up into this PR so we can review and merge shortly after the OEP is merged (4/13).