Issue415 graph ql first steps

[c8y3]

I propose this PR before the code drifts too much away from branch develop.
It is a good small start to introduce the new GraphQL API. (however at this point, it should not be made "public", or only as experimental, because we may want to change the API definition: query and mutation names, field names...)

There are many points that needs to be discussed from here:

• the architectural organization (see in particular https://graphql.org/learn/thinking-in-graphs/#business-logic-layer), the way things are going to be factored with the REST API and the fact that it's quite a lot of, somewhat risky (we don't want to break previous functionalities), work
• the choice of the encoding of identifiers (knowing that graphql integers are only 32 bits, and there are things which don't seem to work well when working with ID, https://graphql.org/learn/caching/#compatibility-with-existing-apis)
• the question about global identifiers (https://graphql.org/learn/global-object-identification/)
• whether we will hide columns with foreign keys (database ids) or not
• the way we will organize the API and naming conventions
• the way we are going to encode relationships and whether we will follow relay conventions (https://graphql.org/learn/pagination/#connection-specification), or we prefer simple lists at first
• hooks, track_activity need for a case id and the fact that hooks may sometimes be called before schema validation and decoding
• the next issues (maybe 2 different issues: one for cases and one for iocs). It would be most productive to design, at least discuss, the API before implementation. Maybe one way to do this could be to start from queries that are most needed in real case studies. (https://graphql.org/learn/thinking-in-graphs/#working-with-legacy-data)

That being said, I think we shouldn't be too ambitious at first and go step by step (https://graphql.org/learn/thinking-in-graphs/#one-step-at-a-time) because we have multiple constraints:

• not to break the existing behavior.
• to add new code within the code base without making too many duplicates
• to take into account COTS. In particular we have witnessed some behaviors that puzzled us (things that do not work as expected, or that are incomplete, or not possible/easy to code) with graphene-sqlalchemy (see Automatic conversion from Int to ID is problematic graphql-python/graphene-sqlalchemy#102 and Discussion: General Mechanism to Selectively Override Automatic Field Creations graphql-python/graphene-sqlalchemy#209)