[main] Remove failure dependency

[onalante-msft]

The failure crate is deprecated and has been superseded by thiserror and anyhow. These changes remove dependencies on failure and replace them by thiserror and anyhow as appropriate.

• Module{,Registry,Runtime}, MakeModuleRuntime no longer have an Error type parameter
• Remove unused submodules of edgelet-core

Azure IoT Edge PR checklist:

This checklist is used to make sure that common guidelines for a pull request are followed.

General Guidelines and Best Practices

• I have read the contribution guidelines.
• Title of the pull request is clear and informative.
• Description of the pull request includes a concise summary of the enhancement or bug fix.

Testing Guidelines

• Pull request includes test coverage for the included changes.
• Description of the pull request includes
  • concise summary of tests added/modified
  • local testing done.

[arsing]

So we're switching from typed errors to untyped anyhow::Error ?

We used to have a bunch of code that depended on the exact error type, specifically one in edgelet-http for setting the HTTP response code appropriately and one related to external provisioning IIRC. Both of those are gone now, so I guess having untyped errors doesn't create any immediate problems, but I worry we're locking ourselves out of ever being able to do anything with the specific errors if we need to.

Edit: As discussed over Teams, the alternative is too much effort - every error variant that's used with .context() has to be changed to have a #[cause] Box<dyn Error + Send + Sync> field; we did this for i-i-s manually but for iotedge there's a lot of errors and a lot of variants. Also, even if we gain a need for typed errors later, we would only have to change the crates involved in the call stack from where the error is generated to where the error is introspected from anyhow to thiserror. So there's no point switching everything to thiserror eagerly.

[onalante-msft]

Also, even if we gain a need for typed errors later, we would only have to change the crates involved in the call stack from where the error is generated to where the error is introspected from anyhow to thiserror.

Another alternative (when performance is not a concern) is downcasting on the errors in anyhow::Error::chain.

[arsing]

(My worry about downcasting is not so much the performance but that it's easy to downcast at the wrong level, and thus not find the error type you were looking for / find a different error of the same type that is irrelevant. You can't make that mistake with typed errors.)

[onalante-msft]

Yes, it would not be something you could do without first getting an idea of what kinds of errors to expect. In any case, we have options for reintroducing typed errors if they become necessary.