Rationalize all the constructor/public functions for coordinator.go

[jlewi]

trafficstars

All of the public functions in coordinator.go for creating/loading KFApps are a bit of a mess

This is the result of a lot of accumulated tech debt.

This has led to problems because the logic is convoluted and different callers are skipping different parts of the logic.

Here are some initial ideas; some of these might be correct but hopefully this can help us accumulating more debt.

• NewLoadKfAppFromURI - This should be the preferred public entrypoint for creating a KFAPp
  • Go style prefers methods named New
• CreateKfAppCfgFile - This should be a private method
• BuildKfAppFromURI - This method should be removed
  • Callers should be migrated to NewLoadKfAppFromURI
  • This code is creating a KFApp and then calling init/generate
  • This doesn't really make sense as public routine
    • Callers should just call NewLoadKfAppFromURI and then invoke generate on the returned app
• LoadKfAppCfgFile
  • After various refactorings NewLoadKfAppFromURI is just a wrapper around LoadKfAppCfgFile
  • We should get rid of either LoadKFAppCfgFile or NewLoadKfAppFromURI and migrate callers to the other function
  • I vote for keeping NewLoadKfAppFromURI because I think its more common in go to call a function named New*

/cc @richardsliu @yanniszark @swiftdiaries @gabrielwen @lluunn @kkasravi @kunmingg

[swiftdiaries]

+1 for NewLoadKfAppFromURI

[lluunn]

Current structure: In build or apply, we call BuildKfAppFromURI

• BuildKfAppFromURI
  • NewLoadKfAppFromURI
    • LoadKfAppCfgFile
      • if remote file, CreateKfAppCfgFile(kfdef)
      • configconverters.LoadConfigFromURI
  • Init
  • Generate

So should instead in build or apply, call NewLoadKfAppFromURI:

• NewLoadKfAppFromURI
  • if remote file, createKfAppCfgFile(kfdef)
  • configconverters.LoadConfigFromURI
  • Init
  • Generate

[lluunn]

I think we can also get rid of Init