Name conflict with FilteringTerm object definitions

[datsirul]

We have encountered an issue with the OpenAPI specifications related to the definition of the FilteringTerm objects.

Problem Details:

The issue arises because the FilteringTerm object is defined in two different locations within the OpenAPI documents, which is causing name conflicts during code generation. Each definition is intended to represent a different object, but they share the same name, as shown below:

framework/src/requests/filteringTerms.yaml

definitions:
  FilteringTerm:
    anyOf:
      - $ref: '#/definitions/OntologyFilter'
      - $ref: '#/definitions/AlphanumericFilter'
      - $ref: '#/definitions/CustomFilter'  

framework/src/responses/sections/beaconFilteringTermsResults.yaml

definitions:
  FilteringTerm:
    type: object
    ...

Due to this duplicate naming, when generating code from the OpenAPI documents (e.g., in Python), the models are generated with conflicting names such as filtering_term.py and filtering_term1.py. This naming conflict can lead to confusion and errors in the generated code, making it difficult to maintain and use.

Possible Solution:

A possible solution to this issue would be to rename one or both of the FilteringTerm definitions to ensure unique and descriptive names that reflect their distinct purposes.

For example, the FilteringTerm definition in beaconFilteringTermsResults.yaml could be renamed to ResponseFilteringTerm while the FilteringTerm definition in filteringTerms.yaml could keep it's short name due to it's frequent use in user requests.

Note:

I understand the current move away from "OpenAPI first" (#40), but I believe this is important as even generated OpenAPI docs may contains this issue.