## New Features

### Event Feed visualization filtering

Select an event type from the Event Feed drop-down menu to display only that event-type on the "guitar string".

### New `chef-automate config` commands.

The new commands allow a user to `show`, `set`, and `patch` Automate's config.

* `chef-automate config show` returns the TOML representation of the current override config that is persisted and applied by the `deployment-service`. Write the TOML to a file instead of `STDOUT` by giving a file path as the first position argument. e.g.:

  `chef-automate config show /etc/chef-automate/config.toml`

* `chef-automate config set` accepts the first positional argument as a path to a file containing the TOML AutomateConfig and makes a configuration set request to the `deployment-service`. There, the `deployment-service` validates, persists and applies the new configuration. The command then streams the converge output to `STDOUT` and exits appropriately, depending on the converge results. e.g.:

  `chef-automate config set /etc/chef-automate/config.toml`

* `chef-automate config patch` updates parts of the configuration without needing to first save and then modify the entire existing configuration. `patch` differs from `set` in the method that configuration is applied.  `patch` accepts a configuration subset, which is merged with the existing Automate config before it is applied, where `set` requires a full and validated configuration. `chef-automate config patch` accepts a positional argument to determine the configuration location. e.g.:

  `chef-automate config patch /etc/chef-automate/enable-debug.toml`

## Improvements

### authz-service: persistance of stored policies

Before, the policies stored in A2 were only kept in memory, and reset on every server restart.
Now, stored policies are persisted to A2's PostgreSQL instance, and thus survive restarts.
In the process, the bootstrapping logic for policies has changed: authz-service now ensures the policies we provide are in the database on startup and forbids deleting them.
For now, this is solved by having fixed IDs for the (three) default policies.

### Extended wildcard matching for "subjects" in policies

Before, the only wildcard option for "subjects" in policies was `"*"`.
Now, in addition to that, partial wildcards are possible, like `"user:local:*"` for any local user, or `"client:*" for any API client.
This enables authorizing API clients to _only post data to the corresponding endpoint_, and not access any other API.

## Bug Fixes
-

## Backward Incompatibilities
- `chef-automate configure-service` no longer exists.
- `chef-automate config fetch` no longer exists.
- `chef-automate config set auth` no longer exists.