Dynamic core contract view calls in the WebAPI

[lmoe]

Right now the WebAPI has hand written controllers to interact with Core Contracts via GET routes. With the now implemented BCS functions, we can now use that to have one handler instead of +50 manual routes.

[nnikolash]

After reviewing existing code and having conversation with Lukas about possible improvements, we decided that this is not a good timing for this task.
One of the main issues is that webapi requires documentation at least of some level of decency. Right now it is implemented using swagger attonations on DTO types in webapi. If we generate everything automatilly and do it in a half-automtic mode (e.g. like EP), there will be no way to even get names of arguments. Such documentations will be not much of use. So we would need to invest effort into implementing some "centralized" documentation (e.g. in EP registations). We decided that this is not such an imprtant improvement to do it now.

FYI here are the options we were reviewing:

• All hand-written handlers (what we have now).
  • Pros:
    • Flexibility.
    • Simplicity.
    • Code already exists.
  • Cons:
    • Need to manually write them. Although there does not seems a lot of them, so maybe its not that bad?
    • Requires manual documentation.
• Multiple generic handlers (manually created) - same as what you implemented for contract calls (that EP stuff).
  • Pros:
    • Homogeneous approach to all handlers (less bugs, higher consistency).
    • No need to write a lot of code.
  • Cons:
    • Need to implement code generator templates.
    • Might require manual documentation, or implementation of automatic documentation.
• Multiple generic handlers (automatically created)
  • Pros:
    • No need to ever edit code of webapi in regards to views
    • All the views are automatically exposed through web api.
    • No bugs related to controllers.
  • Cons:
    • Need to extend code generator templates (EP).
    • Might require manual documentation, or implementation of automatic documentation.
• Single handler just for CallView (already exists):
  • Pros:
    • No need to ever edit code of webapi in regards to views - one route to rule them all
    • All the views are automatically exposed through web api.
    • No bugs related to controllers.
  • Cons:
    • Would need to either manually document or create automatic documentation of all possible inputs for CallView.
    • Less user-friently, then just route per view.
    • The layer is very thin - no possibility for per-argument transformation. The client would need to do all the work.