The interface segregation principle

[Tim Penhey]

Hi folks,

In a recent branch I attempted to remove state.Tools and just have one
definition of tools in tools.Tools.  The whole point of this was to not
have to bring in all of state just to get the tools definition.

Now this was discarded in favour of the option to have a top level agent
package instead of tools.  Unfortunately, agent brings in state, so we
have gained absolutely nothing in terms of dependencies.  If anything,
we have made it worse.

The culprit is agent/agent.go with the definition of the Conf structure,
as it brings in state, state/api and state/api/params.  Each of these
packages are very large.

My second attempt failed with import loops brought on by this exact
issue.  My first though was to move the agent.Conf structure and
methods.  This would then mean that agent only depends on log and
version, which seems like a good minimal dependency set.  However, we
should we move the config to?  One thought is "agent/something".

We as a team have created a spaghetti mess of dependencies.  There are
two main software development principles that we should, but don't, follow:
  * Interface Segregation Principle
  * Dependency Inversion Principle

You can google these very easily, but the fundamental take home points are:
  * only depend on what you need
  * depend on interfaces, not implementations

I have deferred working on the unification of tools until we can agree
on direction.

Tim