Add profile information to modulemd endpoint

[sjha4]

Is your feature request related to a problem? Please describe.
Currently there seems to be no easy way of getting profiles for a modulemd from the API. It would make sense to have that data available at https://docs.pulpproject.org/pulp_rpm/restapi.html#operation/content_rpm_modulemds_read endpoint.

Describe alternatives you've considered
Open to suggestions here for other ways to read this data from pulp if needed.

Additional context
Katello locally indexes module streams and associated profiles. Adding it to the above endpoint will provide a clear way to access this data from pulp.
We might need some data migration for already synced and indexed content especially on the katello db based on how this task is implemented.

[sjha4]

Please also consider description and summary fields in the modulemd endpoint.

[sjha4]

BZ to track it downstream for 6.11.z: https://bugzilla.redhat.com/show_bug.cgi?id=2109634

[dralley]

Consider addressing this alongside #2456 and #2643

If we're going to write these migrations and parse all the same data, might as well.

[dralley]

Actually we do need to be careful now that import/export disregards z-stream.

[ipanova]

To recap the convo that happened on matrix - my preference would be to write a migration that would be adding new fields and in the data repair management command to populate those.

[dralley]

Link to the matrix discussion: https://matrix.to/#/!NLyoXfybQSfvkVRUFB:matrix.org/$4S6z0CApShY1GNkj3_gt5AyQA5vuG1QfUxBVPNO9TSU?via=libera.chat&via=matrix.org&via=ctrl-c.liu.se

I'm shifting back towards the original idea of just doing it in a migration. Reasons:

• I can't see how Katello would reasonably roll it out and we really need to keep the number of cross-dependencies like this to a minimum
• I don't like the idea of having metadata around in an incomplete state. We understand currently that this metadata may be incomplete, but who is to say in 3 years someone won't try to do something which relies on the fields having been filled out properly?
• Originally we thought we would do this prior to pulling module snippets into the database, but we've done the opposite, so we don't need to worry about opening files twice or anything like that

@ggainey @pavelpicka What do you think?

[dralley]

Also this shouldn't be backported. We can put it in 3.18 and then tell Katello they should use that for the 6.12 release but we need to do that soon.

[pavelpicka]

@dralley, @ggainey agree to move it to the migration (mainly because reason no. 2) and also modules are not heavily used yet

[dralley]

@pavelpicka In this same PR could you add "description" and double check with @sjha4 whether there are any other fields that need to be added