Durable SDK breaking changes v2 -> v3 required for essential programming model functioning.

[hossam-nasr]

All of the changes in this issue have already been merged (#389 and #399). This issue is purely for documentation and tracking purposes, to document the breaking changes going from v2.x to v3.x of the Durable SDK, that were essential to get a basic version of the SDK to work the new programming model package.

1. Take a dependency on @azure/functions v4.x

Due to the way the new programming model works, and the split between the Azure Functions worker and the node.js Framework (@azure/functions), the Durable SDK had to move @azure/functions from a devDependency to a dependency, as well as upgrade to v4.x of the package. This comes with all the breaking changes from v3.x to v4.x of @azure/functions, including, but not limited to:

• The type of contexts passed to orchestrations and entities now extend the InvocationContext type from @azure/functions.
• df.getClient() now expects an argument of type InvocationContext
• DummyOrchestrationContext and DummyEntityContext now extend InvocationContext. the InvocationContext object (which the Durable SDK extends) passed to Durable orchestrations, entities, and activities. This also means that now getClient() expects an argument of type InvocationContext from @azure/functions v4.x. This also affects the Dummy More information aboutv4.x` of the node.js Azure Functions Framework package here.

2. Removed df.orchestrator() and df.entity()

The previous df.orchestrator() and df.entity() functions have been removed from the SDK, and have been replaced by new methods under the df.app namespace:

• df.app.orchestration has two overloads:

// takes your generator function as an argument directly
function orchestration(functionName: string, handler: OrchestrationHandler): void;

// takes an options object as an argument 
// currently, the only supported parameter is a handler parameter
// with the generator as value
function orchestration(functionName: string, options: OrchestrationOptions): void;

Both of which create your orchestration function and register it directly with the app.

• df.app.entity() also has two overloads:

// takes your entity function as an argument directly
function entity<T = unknown>(functionName: string, handler: EntityHandler<T>): void;

// takes an options object as an argument 
// currently, the only supported parameter is a handler parameter
// with the entity function as value
function entity<T = unknown>(functionName: string, options: EntityOptions<T>): void;

Both of which also create your entity function and register it directly with the app.

3. Remove dependency on context.done():

In the new programming model (v4.x), context.done() was removed from the InvocationContext object, and instead functions must return their result as the return value of the function. As a result, before, you could do something like this:

const myEntityFunc = df.entity(function (context) {
    // do stuff
});

export default (context) => {
    myEntityFunc(context); // note no `return` here
};

But after the change, such a wrapper around the entity function cannot be registered as an entity. This change should not be relevant in the vast majority of cases though, not only because this was a niche use-case, but also because the semantics of the df.entity() API have also changed (see below).

[hossam-nasr]

Closed by #389 and #399