Quick fix for AnyType ruby bindings

[pedro-psb]

Quicker alternative to #3653 for fixing #3639

I must add that this is not the "correct way" of fixing it, but its quick and safe (in the sense that it leaves us in a similar state we had before, where all jsonfields were recognized as Objects). Its not the correct way because:

• the schema type is misleading, which is not helpful for users. E.g, its says its an Object (openapi type) when its an Array example
• its not doing basic structural validation (often we know exactly what the json structure is)

Reference

• Relevant drf-spectacular docs:
  • https://drf-spectacular.readthedocs.io/en/latest/customization.html#step-3-extend-schema-field-and-type-hints

[pedro-psb]

Given the diff in the clients specs, the unexpected presence of the AnyType in the ruby client is the only cause of the problem.

We don't test the bindings on PR, so to assert that manually you can:

• install the local PR checkout in a venv
• run pulpcore-manager openapi --bindings --component rpm --file rpm-api.json
• move it to a recent pulp-openapi-generator repo local checkout
• run ./gen-client.sh rpm-api.json rpm ruby pulp_rpm
• grep inside pulp_rpm-ruby-client to assert there is no AnyType anywhere

[dralley]

So this seems reasonable to me, but @mdellweg is probably a better judge of correctness. I'd like us to file an issue to revert this change once a "correct" fix is ready though

[mdellweg]

Yes, the would work in isolation for these pulp_rpm fields.

Maybe you want to call it JSONObjectField.

[patchback]

Backport to 3.27: 💚 backport PR created

✅ Backport PR branch: patchback/backports/3.27/2e0c2933675c0ce41d8ac5c801f8d0dbc54349d8/pr-3679

Backported as #3680

🤖 @patchback
I'm built with octomachinery and
my source is open — https://github.com/sanitizers/patchback-github-app.