More possibilities with Modbus-Exceptions

[emcell]

This got a little bigger than I initially expected. I hope you're ok with my changes.

What I've done so far

• Made some types of frame module public
• Converted FunctionCode to an enum and replaced it in a lot of places in codec module. I've done this because I needed the function code in the service handlers to send the Correct ExceptionResponse object.
• Added the GetFunctionCode trait and implemented it on Request and Response. This is also necessary to generate the correct ExceptionResponse in the handlers.
• Added the ExtractExceptionResponse trait. This is for an easy way to downcast the std::io::Error in the clients to ExceptionResponse
• Added a new example that combines the following things:
  • async tcp-server
  • async rtu-server
  • An example of a Service that really uses async and not futures::ready
  • Specifying ExceptionResponses in the Service Layer
  • extracting ExceptionResponse from the client response

I started this because I didn't find ways to specify Modbus-Exception and didn't find a way to extract those in the clients.

I Think this PR should fix #169 and #98.

What could be better here?

I think It would be better to be able to Just return a Result<Response, Exception> from the Service and figure the correct function_code out after the service handler and automatically convert the Exception into ExceptionResult.
But I didn't want to make an even bigger change without speaking to to you in the first place.

[uklotzde]

Why do we need to introduce a public trait? What is the use case?

[emcell]

I've added an example to make this more clear.
Just an easy way to downcast the std::io::Error to the ExceptionResponse if it is one.
I'm also not really with this solution. The better way would be to introduce an Error type for the clients. Could look like this

pub enum Error {
    ModbusException(ModbusException),
    IoError(std::io::Error)
}

This this change it's clear for the api users that a ModbusException exists and can be extracted. On the other hand that could break a lot of builds.
What do you think?

[uklotzde]

Thanks for contributing!

IMHO this PR contains too many unrelated changes. The FunctionCode newtype should be introduced by a separate PR.

[emcell]

any chance this is getting merged soon?

[uklotzde]

Please give this PR a concise title that later becomes the Git commit message.

We also need a changelog entry that summarizes the changes and consequences for users of this crate. Ideally a single sentence for every notable API change. As short as possible.

Everyone is invited to do a review. We are managing this crate in our spare time without any monetary compensation. Please understand that paid projects might be prioritized. Thank you.

[uklotzde]

Should be rebased and updated once #246 has been merged.

[uklotzde]

I will close this PR after seeing no progress lately and because merge conflicts are pending.

Please open a new PR whenever you have something ready. Thank you.