Add support for coming up with a persist policy

[mchalla]

"opflex": {
   "startup": {
        "policy-file": "/home/mchalla/thomas/pol.json",
        "policy-duration": 0,
        "resolve-aft-conn": false
   },

• opflex.startup.policy-file contains pol.json to use at startup
• opflex.startup.policy-duration tells how long in seconds to keep resolving policy from the above pol.json
• opflex.startup.resolve-aft-conn wait till conn before using startup db use in combination with duration > 0
• opflex.startup.resolve-once placeholder for resolving only first time from startup db
• opflex.startup.full-proxy placeholder use startup db for life of opflex meaning startup db will be updated at run time to keep both in sync

If policy-file exists we create a startupdb thats used for intermediate resolves until the leaf connection succeeds based on the above startup-policy-duration

On every local resolve we lookup startupdb and recursively resolve children and put those in the running modb and generating notifications as needed.

On a connect to leaf depending on the above timer and the fact that these threads can run in parallel we will continue to resolve from startupdb while also sending all the resolves to the leaf.

Once the curtime is beyond the set duration functionality reverts to current behavior of only resolving from the leaf.

On stop we write current running policy into pol.json from the config if present.

If the file is missing functionality is same as before.

Change isOrphan to skip check when using startup db since the timing of the sync resolve is causing some valid mos to be deleted as orphans (still investigating an async approach similar to how it would work
with a mock server or leaf)

[mchalla]

I sent out an early request to get more feedback. Pl do not merge it yet.

Some of the feedback from Tom has been addressed and some not yet. Few observations

• deserialize / serialize to return boolean. I realized that may not be needed because the function does some early checks which if not successful will simply return and not insert the object into the MODB. If anything fails later currently we skip the MO and I felt I should do the same so as not to cause the discrepancy in behavior.
• delete the startupdb once we are done. Doing some memory usage testing shows the usage is more or less the same with / without the startupdb (because the MO itself is shared between the 2 DBs). So I didnt want to add another lock simply to remove the db. As such db stop only stops the uri thread that we actually never start here.
• we still need to figure out when to overwrite the policy file and when not to. Like if the restart happens immediately after start i should not overwrite the file otherwise it will result in an almost empty file. I dont have a neat way to do that yet and am still looking at options.