feat!: Add Container.container_code field

[kdmccormick]

Description

Adds a container_code field (code_field) and a learning_package FK to the
Container model. Also adds a UniqueConstraint on (learning_package,
container_code), which is stricter than Component's constraint (no type scoping
-- container codes must be unique across all container types within a given
LearningPackage).

For existing containers, container_code is backfilled from the entity key via a
data migration. Future containers will have container_code set explicitly by the
caller.

BREAKING CHANGE: In create_container() and create_container_and_version(), the
key argument has been renamed to container_code. The same applies to
create_unit_and_version(), create_subsection_and_version(), and
create_section_and_version().

Backup-restore format is unchanged. container_code will be set to the value of
the entity key. This may change in a future "v2" backup format.

Part of: #322

Full series of PRs:

1. feat!: Collection.key -> Collection.collection_code #542
2. feat!: Component.local_key -> Component.component_code #544
3. feat!: Add Container.container_code field #545
4. feat!: Package and Entity keys are now opaque refs #546
5. feat!: ComponentVersionMedia.key -> ComponentVersionMedia.path #547

Testing, AI Usage, and Merge Considerations

See #322

[bradenmacdonald]

I'm fine with this, assuming it's immediately followed by the proper removal of the key field, but I'd prefer to replace key more 1 for 1 as mentioned. Did not run the code, just read.

[ormsbee]

Just a sanity check question, but otherwise LGTM.

[ormsbee]

[Comment, no action needed] It's really unfortunate that we can't use F() across relations. I feel like this is one of the few cases where I'd be tempted to use raw SQL.

[kdmccormick]

Thanks for the review @bradenmacdonald . I've applied all your suggestions except the denormalization check. Could you take another look?

[bradenmacdonald]

Will requiring this code to be unique across all containers in a [course] bite us later when we try to migrate old courses to Learning Core, since they may have e.g. a section and unit with the same container_code ?

[kdmccormick]

Hard to say.

On one hand, we'll likely have multiple course runs per learning package. So, we'll need to handle collisions between container block url_names anyway. I'm imagining that there'll have to be a table which maps CourseRunUsages to Entities, rather than a simple mapping function between {component,container}_{type,code} and CourseRunUsageKeys.

On the other hand, it's weird to me that container_code and component_code have different uniqueness constraints. I have a feeling that the inconsistency will make consuming code more complicated rather than having any benefit to us.

We're riding the line now, but maybe we can sneak a fix to this in before the cutoff.

[bradenmacdonald]

Yeah, I'd prefer to make container_code work like component_code if we can.

[bradenmacdonald]

Looks great! I read through the code, but didn't test; let me know if you want any testing on these PRs.

[kdmccormick]

@bradenmacdonald all set for now, but if you if you have time on Wednesday I could use a hand testing the openedx-platform PR.