[Enhancement] Get rid of all `unwrap`, `expect` and `panic` outside test code

[Davidson-Souza]

Describe the enhancement

Since we are a lib, we shouldn't panic on behalf of our users. They should be notified that something wrong happened, and decide whether to panic or not. For that reason, I suggest we remove all call to unwrap, expect and panic that are not test code. Then add CI checks to deny them being reintroduced.

Use case

This makes the life of the api consumers easier, since panics arriving inside our code are hard to debug by them. This creates some difficulty on our side (panic'in and calling it a day is way easier than making sure you propagate errors in a sane way), but makes lives of upstream coders way better.

[JoseSK999]

But only remove them in the cases we expect them to possibly be triggered right? E.g. if we know a vector has an element doing .first().unwrap() is correct.

[luca0x46]

I thought about using a flag to treat unwrap as error and stop compiling but then it would disable these cases as well @JoseSK999

[jaoleal]

But only remove them in the cases we expect them to possibly be triggered right? E.g. if we know a vector has an element doing .first().unwrap() is correct.

There are some ways to prove that a function call is infallible

[Davidson-Souza]

But only remove them in the cases we expect them to possibly be triggered right? E.g. if we know a vector has an element doing .first().unwrap() is correct.

If you can prove that, I would recommend using expect and explaining why in the string.