Proper Error types for the crate

[alexsnaps]

Fixes #131

This is a first pass at this. LimitadorError::InterpreterError will "only" be used as a mean to cover for runtime errors, e.g. an expression that can't be resolved (see #385). Also, when doing that work, we should be able to return to a Limit::new -> Self over the current result and clean that API up a bit.

Pretty sure other cases will emerge for Limitador::Error as we move towards v2.0 of the server, but hopefully v1 for the crate 🤞

[eguzki]

LGTM

[eguzki]

nit:
out of curiosity, why do we need to add this implementation?

When I apply this patch, it is not needed.

diff --git a/limitador/src/errors.rs b/limitador/src/errors.rs
index d590aaf..3de262e 100644
--- a/limitador/src/errors.rs
+++ b/limitador/src/errors.rs
@@ -1,6 +1,5 @@
 use crate::limit::ConditionParsingError;
 use crate::storage::StorageErr;
-use std::convert::Infallible;
 use std::error::Error;
 use std::fmt::{Display, Formatter};
 
@@ -43,9 +42,3 @@ impl From<ConditionParsingError> for LimitadorError {
         LimitadorError::InterpreterError(err)
     }
 }
-
-impl From<Infallible> for LimitadorError {
-    fn from(value: Infallible) -> Self {
-        unreachable!("unexpected infallible value: {:?}", value)
-    }
-}
diff --git a/limitador/src/limit.rs b/limitador/src/limit.rs
index 94b95b1..511f083 100644
--- a/limitador/src/limit.rs
+++ b/limitador/src/limit.rs
@@ -1080,7 +1080,7 @@ mod tests {
             limit1.namespace.clone(),
             limit1.max_value + 10,
             limit1.seconds,
-            limit1.conditions.clone(),
+            vec!["req.method == 'GET'"],
             limit1.variables.clone(),
         )
         .expect("This must be a valid limit!");

Not arguing to change it, just curiosity.

[alexsnaps]

When you pass an iterator of Condition which are TryFrom... but Infallible.
It'll go away, when I deal with the rest of the refactoring, but yeah... It is perfectly fine to pass Conditions right in the Limit that you know cannot fail.