[Bro-Dev] Rethinking Broker's blocking API

[Matthias Vallentin]

> Sorry, that was misleading. Statuses don't provide an operator bool.
> They could, however, to distinguish them from errors.

Mulling over this more, I'm not sure if it's clear which status codes
constitute an error. For example, there's a peer_lost and peer_recovered
status code. Is only the first an error? Some users may consider peer
churn normal.

Here's the list of all status codes:

    enum class sc : uint8_t {
      /// The unspecified default error code.
      unspecified = 1,
      /// Successfully added a new peer.
      peer_added,
      /// Successfully removed a peer.
      peer_removed,
      /// Version incompatibility.
      peer_incompatible,
      /// Referenced peer does not exist.
      peer_invalid,
      /// Remote peer not listening.
      peer_unavailable,
      /// An peering request timed out.
      peer_timeout,
      /// Lost connection to peer.
      peer_lost,
      /// Re-gained connection to peer.
      peer_recovered,
      /// Master with given name already exist.
      master_exists,
      /// Master with given name does not exist.
      no_such_master,
      /// The given data store key does not exist.
      no_such_key,
      /// The store operation timed out.
      request_timeout,
      /// The operation expected a different type than provided
      type_clash,
      /// The data value cannot be used to carry out the desired operation.
      invalid_data,
      /// The storage backend failed to execute the operation.
      backend_failure,
    };

If we provided operator bool() for statuses, then it would be true for
peer_added, peer_removed_, peer_recovered, and false for all others.
This selection seems arguable to me, which is why I'm inclined to let
users probe for specific instances themselves.

    Matthias