Change return type of decodeJson to FutureOr in order to be able to support compute()

[techouse]

This partially addresses #158 and is mostly based on @lejard-h's suggestion #158 (comment)

This is a breaking change as it changes the response types of some JsonConverter methods, namely:

• decodeJson now returns FutureOr<Response>

  /// before
  Response decodeJson<BodyType, InnerType>(Response response) {
    /* sync decode stuf */
  }
  
  /// after
  FutureOr<Response> decodeJson<BodyType, InnerType>(Response response) async {
    /* async decode stuff */
  }

• convertResponse now returns FutureOr<Response<BodyType>>

  /// before
  @override
  Response<BodyType> convertResponse<BodyType, InnerType>(Response response) {
    /* sync convert stuff */
  }
  
  /// after
  @override
  FutureOr<Response<BodyType>> convertResponse<BodyType, InnerType>(Response response) async {
    /* async convert stuff */
  }

• tryDecodeJson now returns FutureOr<dynamic> and is now public

  /// before
  dynamic _tryDecodeJson(String data) {
    /* decode json */
  }
  
  /// after
  FutureOr<dynamic> tryDecodeJson(String data) {
    /* now you can override this method and use compute to decode json */
  }

• convertError now returns FutureOr<Response>

  /// before
  @override
  Response convertError<BodyType, InnerType>(Response response) {
    /* sync decode error */
  }
  
  /// after
  @override
  FutureOr<Response> convertError<BodyType, InnerType>(Response response) async {
    /* async decode error */
  }

• responseFactory now returns FutureOr<Response<BodyType>>

  /// before
  static Response<BodyType> responseFactory<BodyType, InnerType>(Response response) {
    /* stuff */
  }
  
  /// after
  static FutureOr<Response<BodyType>> responseFactory<BodyType, InnerType>(Response response){
    /* stuff */
  }

[techouse]

This PR most likely needs further scrutiny as it is breaking.

[vaetas]

Is there a reason to use FutureOr instead of Future in this context? I somehow understand the difference between the two. I am not sure about the technical implications here. I am very curious though.

The API request itself must be Future. Does it therefore matter that inner methods are FutureOr?

[techouse]

Is there a reason to use FutureOr instead of Future in this context? I somehow understand the difference between the two. I am not sure about the technical implications here. I am very curious though.

The API request itself must be Future. Does it therefore matter that inner methods are FutureOr?

Both convertRequest and converResponse of the parent Converter are FutureOr.

On top of that one can override a FutureOr to be sync, I.e. FutureOr<Response> can be overridden just as Response (what it currently is in the stable release).

[techouse]

I had to pin analyzer to >=4.1.0 <4.3.0 because v4.3.0 deprecates Element.enclosingElement and advises to use Element.enclosingElement2 which is not present in v4.2.0 and below.

It's more or less an issue with the Github Action because it doesn't use lock files but rather upgrades to the latest dependencies.

[JEuler]

Hm, I'm returning to this thing. As it is breaking we will need to double think it. Personally, I think we can go with your both PR's.
@stewemetal What do you think? :)

[JEuler]

So, I will merge both of your PRs and create a new major update of the Chopper. Thank you for the great work. I think I will do this tomorrow!