[sup] Introduce optional application environment qualifier on Service Group

[fnichol]

This change adds a new optional qualifier to a Service Group string,
called an Application Environment. The printed representation of a
Service Group with Application Environment delimited with a hash
character and the application name and environment name are delimited
with a period character. For example, a Service Group containing an
application name "twitter" and environment name of "production" would
look like:

twitter.production#redis.cache

The components of the Service Group are as follows:

    twitter   . production  #  redis  . cache
|-application-|-environment-|-service-|-group-|

To load a service, 2 new options are added which are used together
(--application/-a and --environment/-e). For example:

hab svc load core/redis \
  --group cache \
  --application twitter \
  --environment production

[thesentinels]

Thanks for the pull request! Here is what will happen next:

1. Your PR will be reviewed by the maintainers
2. If everything looks good, one of them will approve it, and your PR will be merged.

Thank you for contributing!

[reset]

@fnichol per our conversation on the walk over to the stadium, I think we should swap this to a single flag and just go with a naming convention of including a dot - that way this becomes a) tagging mechanism that visualizers of ring data can leverage and b) potentially something we can leverage as a small world in our gossip protocol at a later date

[reset]

Actually, after thinking this over and then having a chat with @adamhjk about it this morning I think this is the right way to go. I think we are actually overloading the concept of "group" and these acting as more than just a label is the right way to go. Moving forward I think we should restructure things like this:

• Application - a collection of services working together to provide an experience
• Environment - an application providing an experience in a logical environment (acceptance, live, etc)
• Group - a grouping of same services within an application. This could be something like blue or green. I think we will more often then not see group just as "default" if we make this change

What is also great about this change is we finally have an actual solution for how to assemble a "small world" in the gossip protocol for garbage collection and faster spreading of rumors at scale.

Gonna do a code review on this one last time and then get it merged in.

[reset]

@fnichol this looks perfect as is, we can pipe things into the gossip layer and make any necessary changes in a future commit!

[reset]

@thesentinels approve

[thesentinels]

🤘 I am testing your branch against master before merging it. We do this to ensure that the master branch is never failing tests.

[thesentinels]

Travis CI has started testing this PR.

[thesentinels]

💔 Travis CI reports this PR failed to pass the test suite.

The next step is to examine the job and figure out why. If it is transient, you can try re-triggering the Travis CI Job - if it passes, this PR will be automatically merged. If it is not transient, you should fix the issue and update this pull request, and issue approve again. If you believe it will never pass, and you are feeling , you can issue a force to merge this PR anyway.