Flexibility refactor

[ajbalogh]

The current version of infra.proto is not flexible enough to accommodate better device reuse, more complex topologies and external third party data. At this time there is also no specific rpc for model validation. In addition there is code that builds concrete infrastructure objects that is application specific and should not be part of this repository.

This PR will address the following:

• removal of application specific samples
• binding proto that allows application specific data to be bound to various infrastructure paths
• service proto that initially provides a validation rpc
• validation rpc implemented as a class intended for local use only (no grpc server/client needed)
• unit tests focused on model validation
• additional comments in proto files

[thomas-am]

It would be nice to show the intended use, and give a couple examples what to use bindings for...
Either in readme or as a test case.

[ajbalogh]

It would be nice to show the intended use, and give a couple examples what to use bindings for... Either in readme or as a test case.

Added a few examples at the top of the bind.proto file

[ajbalogh]

Removed the linktype as it adds overhead and opens the link message to interpretation. The bandwidth message in the link is the most important piece and is required. A description field has been added instead so that additional details describing the link can be provided. To categorize the link the bind.proto should be used. @harsh-sikhwal

[ajbalogh]

Revised the bind.proto to allow a user to specify multiple bind targets to one user defined data message, prior to this change you had to repeat the user defined message if it was to be applied to multiple disparate instances.

[Ricefrog]

In general, I approve of the change. I think this technically covers every way that a binding might be attached to a subset of the entire infrastructure, with a potential drawback being targets lists that are very large.

[ajbalogh]

In general, I approve of the change. I think this technically covers every way that a binding might be attached to a subset of the entire infrastructure, with a potential drawback being targets lists that are very large.

re: target lists can get large - this buys time to evaluate alternate scaling techniques for indexing and avoid api churn