Runtime should be able to directly consume webjobs dlls

[MikeStall]

The Functions runtime should be able to directly consume webjobs dlls.
Today when using VS tooling,

1. we start with WebJobs C# source files,
2. run a tool to create a Function.json that points to the compiled C# via the precompiled hook,
3. then load in Functions runtime, and
4. ref.emit to generate a C# wrapper that matches the original source files.
   We should skip steps 2...4 and just consume the webjobs dll directly.

Notes by @lindydonna:

• If isGenerated flag is missing or false, script runtime should fall back to the old behavior and use function.json.
• Runtime should emit a warning if function.json trigger does not match attribute, as this means the scale controller and runtime would be out of sync.

Tasks:

Support changes: (other bugs we need to fix already)

• Move non-invoke code out of the invoker coder path (Metrics for C# Functions should include input bindings #578)
• SDK work for new instrumentation endpoint to support that
• Return values: Return value support for BYOB azure-webjobs-sdk#1104
• FunctionName attribute SDK should Honor FunctionName attribute  azure-webjobs-sdk#1170
• Disabled - we'll use [Disabled] attribute.

Process

• add new direct load support
• private drops available
• verify existing bugs fixed.

[MikeStall]

Initial investigation looks promising. Just adding the compiled types to the TypeLoader in ScriptHost is enough to execute them. It looks like all of the Ref.Emit round-tripping is really to support the instrumentation that we have in FunctionInvoker.InvokeCore. But the SDK can provide a function begin/end hook to enable this instrumentation (Very similar to what we already do in fast-logger).

[fabiocav]

I'd expect that bringing them in directly would work, but we need to address some of the scenarios we've discussed (e.g out of proc). I think we really need to consider going with a metadata only approach from an SDK's perspective, instead of using the attributes. We can't expect to be able to load and inspect those assemblies in all scenarios.

[MikeStall]

Solving #578 will make this much easier because it addresses the issues we have around FunctionInvoker.InvokeCore.

[fabiocav]

Yes. Ideally, we'd solve #578 in a way that removes the need for the metrics logic in InvokeCore

[paulbatum]

Flagging this as potentially breaking. Here is how a customer gets broken:

1. Create a precompiled function app and deploy it.
2. Use the integrate tab to change a configuration setting such as a queue name
3. This change goes out, the runtime stops honoring the queue name in their function.json and reverts to using the queue name hard coded into the attribute in their dll.

If we don't want this to be breaking, the behavior has to go behind some type of flag, or we have to use function.json first and fallback to the attributes. Need to think about the exact semantics to use for the fallback.

[lindydonna]

Resolution to break: VS tooling adds a property "isGenerated": true to function.json. If this property is missing or false, then function.json takes precedence. Removing "breaking" label.

[lindydonna]

Removing the "engineering" label as it does have some customer impact, wrt to "isGenerated"