Consider reworking error kinds in milli

[dureuill]

As of v1.8, milli exposes the following error kinds:

pub enum Error {
    InternalError(InternalError),
    IoError(io::Error),
    UserError(UserError),
}

With roughly the following semantics:

• InternalError: an invariant does not hold (bug); unexpected DB state (e.g. missing dbs or missing mandatory keys in DB); could not read/write from DB
• IoError: an I/O operation failed
• UserError: Error caused by user behavior, like configuration error (trying to a open a directory that is not a DB, passing something that is not a URL where it should be, etc), reaching build-in limits (in the number of attributes, documents), query errors (invalid filter, no primary key)

This has the following limits:

1. DB corruption errors are mixed with bugs. It would probably be interesting to have BugError on one hand for checks that should never fail if the code is correctly written, and DbConsistencyError or DbCorruptionError for checks that should never fail on a sane DB.
2. DB read/write errors are mixed with bugs. They should probably be considered the same as IoError.
3. IoError is too specialized and there's no error kind for similar errors that originate with the environment but are not std::io:Errors. e.g. "could not resolve URL", heed errors that happen because file permissions are not good, or there is no space left on device for the write operation to succeed.
4. There is no kind of errors for errors that are difficult to categorize. For example, when a URL cannot resolve, it could be either because the remote server is down (e.g. OpenAI), because the network link is down, or because the passed URL is wrong. This error does not fit squarely in any of the existing categories (is "OpenAI being down" a UserError?).

---

This issue proposes a new error categorization.

• LogicError: Errors that happen only if the code is not correctly written. To be decided, could also be just panics. Expected response: user checks that no similar issue is open, then they open a new issue.
• DbCorruptionError or DbConsistencyError: Errors that happen only if the database is not in the expected state. Can be a bug, or can be an issue with the filesystem of the DB. Expected response: users read through a warning that indicates the situations where Meilisearch should not be used (network filesystems, mostly) and check they aren't in these situations. If they aren't in these situations, then they check that no similar issue is open, then they open a new issue.
• EnvironmentError: Errors that happen only if something is wrong with the state of the world: an I/O operation failed, a DB R/W failed, a server that we were able to talk to previously (so URL is OK) stops responding or responds with error 5xx. Expected response: users check the environment (machine state, remote server state)
• UserError: Errors that happen only if something is wrong with the configuration or requests from the users. The user misconfigured something, or hit one of the built-in limits, or passed an invalid filter, etc. Expected response: users check their configuration, requests, etc.
• RuntimeError: Errors that can happen if something is wrong either with the state of the world or with the configuration or request from the users. For example, when trying a URL for the first time, the server doesn't respond. Is the server down, the link down, or the URL wrong? Expected response: users check both their configuration and environment.

Breaking changes as the new error kinds will result in new error codes and cause old error codes to disappear.