Adds simple state tracking

[wrgeorge1983]

This approach is probably a dead-end, but perfect being the enemy of the good in this case I think I can make the case for including it anyway.

Even if this never makes it into master, honestly. As long as it's up here and tagged so that Golang can find it with "go get", we can use it in other projects.

The requirements for this to be findable with "go get" are that it needs to be tagged with a "semantic versioning" tag. i.e. "v0.0.1" or some such. "v0.0.0" is what go uses if it can't find a tag, so best not to use that.

Tagging it that way let's us write dockerfiles like:

FROM golang:1.15.0-buster
ENV VERSION=v0.0.1
RUN go get github.com/tbotnz/cisgo-ios@${VERSION}
CMD go run github.com/tbotnz/cisgo-ios@${VERSION}

[wrgeorge1983]

Also tagging/referencing it this way makes it effortless to consumers to select the version they need for the usecase in front of them. Especially if there's not total feature parity between the two branches.

[tbotnz]

Looks like a decent start, couple of comments.

• can we try to think of other ways of reducing the if count ( it was bad to start with :{D)
• if we want to support config changes then it needs to be done in a way that can be added to, ideally we would use the contextstate map to determine config mode

[wrgeorge1983]

Yeah, ultimately I think this IS a dead-end. Long term it'd make more sense to build off of the work @lykinsbd is doing. I don't really have a basis for speculating what that might look like at this point, but for purposes of pure short-term utility Netpalm can make good use of this functionality today.

And I'm certain there are more elegant ways to approach this, but my command of go syntax is negligible at this point. Would it be possible to merge this into a specific branch labeled something appropriately scary to discourage people from trying to use it or base future work off of it?