Macros framework should allow implementations to choose return type about jsonrpc

[tomusdrw]

The discussed idea was to use associated types:

build_rpc_trait! {
 trait Rpc {
   fn some_method(&self) -> Result<String, Error>;
   fn some_other_method(&self) -> BoxFuture<String, Error>;
 }
}

struct RpcDefault;
impl Rpc for RpcDefault {
   fn some_method(&self) -> Result<String, Error> { unimplemented!() }
   fn some_other_method(&self) -> BoxFuture<String, Error>  { unimplemented!() }
}

struct RpcAsync;
impl Rpc For RpcAsync {
  type some_method = BoxFuture<String, Error>;

   fn some_method(&self) -> BoxFuture<String, Error> { unimplemented!() }
   fn some_other_method(&self) -> BoxFuture<String, Error>  { unimplemented!() }
}

[rphmeier]

This is fine but the naming convention is pretty ugly (and rustc is bound to complain; users will need to use some custom lint settings).
We could require that the mandatory #[rpc] annotation be formatted like this:

#[rpc(name="rpc_nameHere", return=NameHere)]
fn name_here(&self) -> Result<Foo, Error>;

which will generate the associated type with name NameHere instead of name_here . This could be optional but this would introduce further parsing complexity in the macro implementation.

[tomusdrw]

Renamed the issue to support arbitrary return types with Into<BoxFuture<String, Error>> bounds.

We could then provide a special jsonrpc_core::Result type with proper From<Result> and Into<BoxFuture> implementation

[tomusdrw]

The core part of the code already have relaxed requirements and recent switch to proc-macro should allow for more free form types to be returned (for instance an enum encapsulating possible results that implements Into<BoxFuture>)