Rare handler out of sync edge when using both the GUI and CLI (or multiple GUIs)

There still exists a Rare handler out of sync edge when using both the GUI and CLI (or multiple GUIs). 

This is a non-issue (thus an edge case) if the user only uses the CLI to control/manage Eventing or only uses a single UI to control/manage Eventing.

Note the fix to MB-34892 solves most of the sync issue nicely for deletions and additions - the issue described here concerns itself with stale information in the UI for updates of existing handlers and/or their settings.

Consider the case where an Eventing function is undeployed and two different engineers are working on the same function the first one say user A to deploy seems "wins" e.g. his change is deployed and the controls for user B are locked out form making changes.  However used B has made changes in his local UI and those changes are not over wirtten when A "won", now assume B undeploys to do some more work he will NOT see the changes made by A that were deployed.

There are two ways to fix this either "Fix #1" or "Fix #2"

Fix #1 (most likely sufficient)

#1 if the UI knows that the function was deployed by someone (another UI) or something (CLI) else when the "deploying ...." transitions to "deployed" it should call importFunctionFromServer() and update it local view.

We ignore the case of updating an undeployed handler, because this is equivalent to two CLI's doing concurrent updates we only ensure we are resync'd on the completion of any deployment. 

Fix #2 (I think this is best)

Utilize some sort of unique hash against the entire function and put it into the basic stats for eventing from the "loop" getAppStatus() .  Note this returns an array of information for each eventing handler e.g. 

composite_status: "undeployed"

deployment_status: false

name: "verifier_12"

num_bootstrapping_nodes: 0

num_deployed_nodes: 0

processing_status: false

However a quiescent UI will not pick up a change in the the "loop" getAppStatus() from an update of an "undeployed function" via the CLI or another UI (either javascript code changes or setting changes). 

For example the CLI loads a handler with an updated "worker_count" and then the UI is used to deploy the function - you will see the UI never got the updated "worker_count"

As such if we somehow included something unique hash or id to each version of a handler for instance.  A simple cheat would be to include either of the following which seem to be updated on every deploy into the basic stats for eventing from the "loop" getAppStatus() 

function_instance_id: "YFf*W2"

handleruuid: 4276925440

So lets say we add "handleruuid: into the basic stats that getAppStatus() scans in a recurring fashion then hen we merely do the like following to synchronize when the value of "handleruuid"  differs (hopefully there exists an updateApp() function so we don't flash the UI)

ApplicationService.local.deleteApp(appName);

ApplicationService.public.importFunctionFromServer(app.name)

 .then(result => {

    ApplicationService.local.createApp(result.data);

 });

In the case of pure CLI (no GUI involved) this edge case is not an issue as the CLI users are sending complete handlers and in essence know exactly what they want.

In this case if there is an update to an either a deployed (form the GUI and CLI) or undeployed handler (from the CLI) the handler is resync'd.