Blueprint interfaces implementation

[YunchuWang]

Introducing blueprint concepts to new programming model (referenced to flask blueprint)

The benefits of blueprint is:

• separating functions to different python files
• providing extensible, module python classes to enable external parties to implement their own function app types.

New public classes blueprint exposes:

• DecoratorAPI: An abstract class which contains essential decorator function building blocks to extend for creating new function app or blueprint classes.
• HttpFunctionsAuthLevelMixin: Python class which manages(getting/setting) http authorization level property to the extended classes.
• TriggerApi: Interface to extend for using existing trigger decorator functions.
• BindingApi: Interface to extend for using existing binding decorator functions.
• FunctionRegister: Interface for declaring top level function app class which will be directly indexed by Python Function runtime. There can only be one FunctionRegister instance in a function app.
• FunctionApp: FunctionApp instance containing all natively supported decorator functions to capture user defined function and corresponding metadata information.
• Blueprint: Similar to FunctionApp with only difference is BluePrint does not extends FunctionRegister class.
• ExternalHttpFunctionApp: Interface to extend for building third party http function apps.
• AsgiFunctionApp: Top level function app class for constructing asgi http functions.
• WsgiFunctionApp: Top level function app class for constructing wsgi http functions.

[codecov]

Codecov Report

Merging #116 (06601f9) into dev (ce3e24f) will increase coverage by 0.11%.
The diff coverage is 98.92%.

@@            Coverage Diff             @@
##              dev     #116      +/-   ##
==========================================
+ Coverage   89.23%   89.35%   +0.11%     
==========================================
  Files          51       51              
  Lines        2946     2959      +13     
  Branches      393      396       +3     
==========================================
+ Hits         2629     2644      +15     
  Misses        241      241              
+ Partials       76       74       -2     

Flag	Coverage Δ
unittests	89.32% <98.92%> (+0.11%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
azure/functions/decorators/__init__.py	100.00% <ø> (ø)
azure/functions/decorators/function_app.py	99.40% <98.91%> (+0.65%)	⬆️
azure/functions/__init__.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ce3e24f...06601f9. Read the comment docs.

[vrdmr]

@YunchuWang - As this is only used for registering blueprints, should be call is register_blueprint? or you are using this to register for other other generic cases? We can use pointers to functions and use specific handlers for such cases.

Define a generic _register_functions

def _register_functions(...):
 ...

and then

register_blueprint=_register_functions
register_wsgiapp=_register_functions
...

such that it is easier to understand what the method would actually be used for.

[YunchuWang]

it can be used to register custom defined classes extending triggerapi or bindingapi or both. i am thinking aliasing a register_blueprint and keeping register_functions public to register any other types of custom defined function container classes?

[vrdmr]

So - this would be used by the Worker now?

/cc @gavin-aguiar

[YunchuWang]

yes, need to make change on worker to index FunctionRegister instead of functionapp

[vrdmr]

we have to think for the future - if auth_level is set and no HTTP function is registered - we should give some sort of a warning - just in case. Not for this PR.

[YunchuWang]

will add a task for this

[vrdmr]

LGTM