Add support for aggregation queries as defined in the OData aggregation Spec

[manukahn]

We have extended the Syatem.Web.OData project to provide support for aggregation queries on top of OData.
Now It is possible to parse aggregation queries and create the required objects for ASP.NET to implement OData aggregation

[azurecla]

Hi @manukahn, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, AZPRBOT;

[xuubin]

Hi Manukahn,

First of all, thanks for your contribution. The code looks great, it implements the groupby, filter and aggreate in an elegant way.

We have put some comment in your code, could you take a look?

And since aggregation is an extension to the OData, we think that it may be a good way if we can
seperate the aggregation code into a different namespace and assembly, so people can choose to include it or not, and can implement their own one according to their business requirement.

To support this kind of extension, some internal classes and methods must be made public so the thiry dll can extend the UriParser and make use of the existing parse code. Specifically, these needs to be public:

1. The ODataQueryOptionParser propery in ODataUriParser.
2. The intern class ODataUriParserConfiguration.
3. The states in ODataQueryOptionParser, like TargetNavigationSource, TargetEdmType, QueryOptions etc.
4. Some internal methods used to parse filter expression.

We have open a github issue to make these changes, and after that, the ParseApply can be implemented as an extension method to the ODataUriParser, and the code can host in a seperate namespace and dll.

[xuubin]

Hi @manucohenyashar, we've opened an issue 8 to make ODataUriParser extendable to parse apply and other extensions, after that, you can use public methods of ODataUriParser to support the aggregate functionality. We also welcome the contribution to issue 8.