feat(proto): Add unspecified to enum fields (#98)

* style(test): Sort halconfig file

It's easier to find fields if it's sorted.

Also while making trivial changes, format the markdown files
with prettier.

* feat(security): Remove unused enum

This enum was only used by Halyard to track they type of OAuth
provider you had configured; it used this to set other fields
when you ran hal commands.

A while back I updated the documentation on spinnaker.io to
show users how to set the required fields themselves (which is
useful both for directly editing your hal config with Halyard, or
for early adopters of kleat).

We can remove this field as it is not used. I'll add a note to the
changelog about this. Existing Halyard users would already have had
the other fields filled out based on that field when they ran hal
commands, so I'm not including this as a breaking change. New users
will need to set their config fields themselves using the documentation
on spinnaker.io.

* feat(proto): Add unspecified to enum fields

We want to distinguish unspecified enums from enums set to their
default value. Let's do this by making the default value in each
enum be a sentinel UNSPECIFIED value. This means that when the
field is not specified, it will be deseriazlied as UNSPECIFIED,
and will be omitted from re-serialization. Any valid value will
be included in serialization.

Author: ezimanyi

CONTRIBUTING.md

@@ -94,6 +94,16 @@ that has been omitted from the config and a field that has has been explicitly
 set to its default value. The output config will include the field even when it
 has been set to its default value (`""`, `0`, `false`).
 
+In the case of `enum` fields, the absence of a value is treated the same as the
+value assigned to constant `0` (which is required and must be the first value in
+the enum). In particular, this means that an enum set to its zero value will not
+be included in serialization.
+
+In order to distinguish enum fields that are unset from those set to their
+default value, a value `UNSPECIFIED` can be added as the first enum constant. In
+this way, configs that don't specify the value will be deserialized to
+`UNSPECIFIED` and will omit the field on re-serialization.
+
 #### General rules
 
 The general rule is that `string` and `int32` fields should rarely be wrapped,
@@ -105,3 +115,7 @@ On the other hand, it generally is meaningful to distinguish between omitting a
 something to `false` is meaningful and distinct from not setting it at all (even
 if the consuming code currently defaults the field to `false`). For this reason,
 all `bool` fields should be wrapped as `BoolValue`.
+
+Likewise, it is generally meaningful to distinguish an unset enum field from one
+that has been set. Thus `enum`s should always have `UNSPECIFIED = 0` as their
+first value.

README.md

@@ -7,9 +7,9 @@ replace Halyard. Please see the
 [RFC](https://github.com/spinnaker/governance/blob/master/rfc/halyard-lite.md)
 for an overview of what this tool will do.
 
-It is currently under active development, but is ready for early adopters
-to try in development clusters! Please share any feedback in the #kleat
-channel in [Spinnaker slack](join.spinnaker.io).
+It is currently under active development, but is ready for early adopters to try
+in development clusters! Please share any feedback in the #kleat channel in
+[Spinnaker slack](join.spinnaker.io).
 
 ### Migrating from Halyard