Label derive macro

[emschwartz]

Right now, autometrics adds the return type as a label if the concrete types in a Result<T, E> implement Into<&'static str>.

It would be better if Autometrics had its own Label derive macro that you would use with your enums. That would make it more explicit that you're opting into making that a label.

One thing to consider: if you have a Result type, it currently uses the label ok="variant_name" or error="variant_name". If you wanted to include a label from a function parameter instead of the return value, we'd probably want the label to be something like type_name="variant_name". If we do that, should we change the behavior for Results so you have the same type_name="variant_name" label or is it helpful to have a standard error="variant_name label?

[emschwartz]

Ah, maybe we could tackle this use case as well as #34 together by defining the following traits:

pub trait ReturnTypeLabel {
  /// Implement this method to show the type as a label.
  /// Depending on whether the return value is `ok` or `error`,
  /// the label will be `ok="label_value"` or `error="label_value"`
  fn label_value(&self) -> Option<&'static str> {
    None
  }

  /// Implement this method to control whether this value should be considered
  // "successful" or not. If this returns `Some(true)`, the label `result="ok"`
  // will be attached. If it returns `Some(false)`, the label `result="error"` will be used.
  fn is_ok(&self) -> Option<bool> {
    None
  }
}

/// When this trait is implemented for an autometrics-instrumented function parameter,
/// the given label key and value will be attached to the generated metric (`label_key="label_value"`).
pub trait ParameterTypeLabel {
  fn label_key(&self) -> &'static str;
  fn label_value(&self) -> &'static str;
}

One thing I'm not sure about is whether there should also be a label_key method on the ReturnTypeLabel. It seems somewhat useful to standardize having the error="error_type", but maybe it's more helpful to allow users to stipulate their own label keys.

[emschwartz]

As discussed with @sagacity, we're currently leaning towards having a trait like this:

pub trait GetLabel {
  fn get_label(&self) -> Option<(&'static str, &'static str)> {
    None
  }
}

This can be used for both return types and parameters. This means we won't have the label keys ok and error anymore, but will instead add the enum type name as the key.