Adds features implemented to docs usage

[seanparkross]

Includes features which this NDC implements and links to docs for each.

Inline with the ndc-connector-template

[soupi]

Looks good. I have some comments.

I do have a question about why we are adding this information here. It seems to talk about a higher level of abstraction, which is GraphQL API for all connectors which implement ndc-spec, and is not specific for this connector.

Perhaps this should go in a central place and be linked from this repository (and other connectors' repository) instead?

[soupi]

I find it unfortunate that the term arguments is overloaded and may also refer to collection arguments.

I would actually suggest that this section is unnecessary, because we've already showed in simple-queries.md that we can use multiple arguments (limit and offset).
Another suggestion is to fold this into simple queries.
wydt?

[seanparkross]

1. Can we use the term "query arguments"?
2. I don't mind it that much. I think it's handy to be explicit (especially for the AI bot which is becoming the de-facto method of using docs) The simple queries page is fairly long already. If you have very strong feelings about this Gil we can change it. CC: @robertjdominguez

[soupi]

Suggested change

	If multiple queries are part of the same request, they are executed **sequentially**, the individual responses are
	collated and returned together. You can fetch objects of different unrelated types in the same query.
	You can fetch objects of different unrelated types in the same query.

Should we include implementation details here if they are not semantically meaningful? There's no reason why we can't run the queries in parallel, or run them all in a single query, and keep the same semantics.

[seanparkross]

Is this something that would need to change with the connector to implement?

[soupi]

Yes it is entirely the connector's decision how to implement this.

[seanparkross]

Accepted suggestion

[soupi]

_nin does not currently exist in ndc-spec, only _in. I think using _not over _in does the same thing?

[seanparkross]

Have updated. Can you check that it's correct in the second example.

[soupi]

Computed fields are currently not supported.

[seanparkross]

deleted and removed from indices

[seanparkross]

Hey Gil :)

I do have a question about why we are adding this information here. It seems to talk about a higher level of abstraction, which is GraphQL API for all connectors which implement ndc-spec, and is not specific for this connector.

The decision was made (after much back and forth, analysis and conversation), that all connector specific docs, including GraphQL API docs, would live in their respective repos... because:

• All connectors will enable slightly different features and functionality. Managing those differences, however slight (especially the slight differences), in a central place has proven to be difficult in v2 and would be predicted to become more so in v3 with the intended (high) number of connectors which will eventually be added.

• Developers would need to update two places to update their connector and the docs for them. With approval processes and timelines it would lead to out of sync features and docs.

• We want to set a precedent and common format for how the public will document their community connectors, in line with how we document ours.

• Connectors will likely also at some point enable other APIs besides GraphQL (REST, gRPC). Some may do one and not the other. Managing these differences in a central place would become difficult.

• If all in-repo connector docs follow a predictable and common template then they should be easy to follow across multiple repos.

• If the connector hub decided to render the docs for each connector from the repo then this methodology can enable that.

Once this PR is approved and this repo is public, we will remove the PostgreSQL GraphQL API docs from the DDN Docs site.

CC: @robertjdominguez @rahulagarwal13 @manasag @codedmart