Support for composable functions

[MartinM85]

fixes #402
fixes #404

Generate ODataPath for composable functions

[MartinM85]

Proposal of a fix for #402.

Now, ODataPath is not generated for composable functions

../operation/operation

Example from Graph API v1.0 metadata.xml

      <Function Name="lastCell" IsBound="true" IsComposable="true">
        <Parameter Name="bindparameter" Type="graph.workbookRange" />
        <ReturnType Type="graph.workbookRange" />
      </Function>

      <Function Name="visibleView" IsBound="true" IsComposable="true">
        <Parameter Name="bindparameter" Type="graph.workbookRange" />
        <ReturnType Type="graph.workbookRangeView" />
      </Function>

      <Action Name="unmerge" IsBound="true">
        <Parameter Name="bindparameter" Type="graph.workbookRange" />
      </Action>

      <EntityType Name="workbookRangeView" BaseType="graph.entity">
        <Property Name="cellAddresses" Type="graph.Json" />
        <Property Name="columnCount" Type="Edm.Int32" Nullable="false" />
        <Property Name="formulas" Type="graph.Json" />
        <Property Name="formulasLocal" Type="graph.Json" />
        <Property Name="formulasR1C1" Type="graph.Json" />
        <Property Name="index" Type="Edm.Int32" Nullable="false" />
        <Property Name="numberFormat" Type="graph.Json" />
        <Property Name="rowCount" Type="Edm.Int32" Nullable="false" />
        <Property Name="text" Type="graph.Json" />
        <Property Name="values" Type="graph.Json" />
        <Property Name="valueTypes" Type="graph.Json" />
        <NavigationProperty Name="rows" Type="Collection(graph.workbookRangeView)" ContainsTarget="true" />
      </EntityType>

If functions are composable, they can be chained

../operation/operation/../operation

I have a restriction that only one operation segment can be appended

It's not a fix for #404 which is a case when a navigation segment is added to the operation segment

I can add the navigation segment

...
AppendPath(newOperationPath);

if (edmOperation.ReturnType != null && edmOperation.ReturnType.Definition is IEdmEntityType returnBindingEntityType)
{
    foreach (var navProperty in returnBindingEntityType.NavigationProperties())
    {
        ODataPath newNavigationPath = newOperationPath.Clone();
        newNavigationPath.Push(new ODataNavigationPropertySegment(navProperty));
        AppendPath(newNavigationPath);
    }
}

but newNavigationPath.Kind is calculated as Operation and it will break the code in

OpenAPI.NET.OData/src/Microsoft.OpenApi.OData.Reader/PathItem/OperationPathItemHandler.cs

Line 75 in aaa82b3

ODataOperationSegment operationSegment = path.LastSegment as ODataOperationSegment;

[MartinM85]

The second commit contains fix for #404

[baywet]

Thanks for the great contribution! In addition to my comments, could you add unit tests for the case you're implementing please?

[MartinM85]

Added unit test and small changes to ensure that operations are appended to all composable functions, and navigation properties are appended to functions.

[baywet]

Thanks for making the changes! @irvinesunday for final review and merge

[irvinesunday]

Wanted to add this diff screenshot for informational purposes.

The diff image above shows the current number of paths per API generated using the Kiota-based CSDL for v1.0.
Left is current production figures, right is with the changes in this PR.

Below is a similar diff but using the non Kiota-based CSDL (PowerShell and Graph Explorer)

Left is current production figures, right is with the changes in this PR.

drives API seem to have grown by quite a huge margin. We may need to investigate the accuracy of the operations bound to the drives API and and fix them in the metadata if necessary before merging this PR.

[irvinesunday]

@MartinM85 do you mind updating the release notes and bumping up the version in the csproj file?

[MartinM85]

@irvinesunday Version and release notes updated

[irvinesunday]

Wanted to add this diff screenshot for informational purposes.

The diff image above shows the current number of paths per API generated using the Kiota-based CSDL for v1.0. Left is current production figures, right is with the changes in this PR.

Below is a similar diff but using the non Kiota-based CSDL (PowerShell and Graph Explorer)

Left is current production figures, right is with the changes in this PR.

drives API seem to have grown by quite a huge margin. We may need to investigate the accuracy of the operations bound to the drives API and and fix them in the metadata if necessary before merging this PR.

Investigation to the growth in the drives API is tracked with this issue.

[irvinesunday]

Tested this again, the changes are acceptable, and this PR can be merged.

v1.0

beta

[baywet]

@irvinesunday, thanks for double checking. Did you have to make any changes to the metadata? Any changes we should make to the test CSDLs here considering the bigger increase in path items? (see the integration tests numbers)

[irvinesunday]

@irvinesunday, thanks for double checking. Did you have to make any changes to the metadata? Any changes we should make to the test CSDLs here considering the bigger increase in path items? (see the integration tests numbers)

No, I didn't make any changes to the metadata. The integration file is probably falling behind the main metadata file in terms of annotations.

[baywet]

@irvinesunday would you mind having a quick look at those to check if something obvious comes up? (like a wrong contains target or a missing annotation) so we can keep those numbers down?

[baywet]

Thanks everyone for the work on this one.
@irvinesunday for final review and merge.

[irvinesunday]

@baywet our biggest culprit was a containment for a directoryObject type navigation property that also had a collection of derived types.

<NavigationProperty Name="deletedItems" Type="Collection(graph.directoryObject)" ContainsTarget="true">
  <Annotation Term="Org.OData.Validation.V1.DerivedTypeConstraint">
    <Collection>
      <String>microsoft.graph.user</String>
      <String>microsoft.graph.group</String>
      <String>microsoft.graph.application</String>
    </Collection>
  </Annotation>
  <Annotation Term="Org.OData.Core.V1.ExplicitOperationBindings">
    <Collection>
      <String>microsoft.graph.restore</String>
    </Collection>
  </Annotation>
</NavigationProperty>

Removing the containment (as we've done in our prod files) lowers the path numbers here significantly.
The integration file and our prod file are still not 100% a match but nothing else out of the ordinary stood out.
We can merge this.