isValidTransaction dropped in favour of checkCanBeSpent for custom validations

[juan-cortes]

Simple fix for #1448 Maybe I misunderstood the function of isValidTransaction but since it wasn't being called I figured it's probably a bug.

[gre]

mmh I think we should probably be able to just use checkCanBeSpent instead (and probably provide a PR that drops isValidTransaction that was way too limited. the fact it's sync and also just return a boolean. checkCanBeSpent is its "async" version that also throw custom errors – that can be translated)

[juan-cortes]

After our talk @gre I've changed the PR to drop isValidTransaction and renamed checkCanBeSpent to a more generic checkValidTransaction. Had to make some small changes to the bridges in order to allow checkValidTransaction to return false for validations of the memo. Hopefully is not too intrusive.

Basically, the promise returned (implicit or explicit) should return a boolean since if we only rely on throwing errors or not I can't disable the continue button while handling the validation on a different input.

[gre]

LGTM, i'll give a quick try on monday

[gre]

Please detail why we need the case of returning "false"? I think we always want to give feedback to user with an error (in failing promise) to inform why it's blocking.
and if we don't, we probably just should ignore a given error to not display it.

NB: i'm currently in progress of refactoring all of these functions in our mobile implementation in order to unify things a bit better between the 2 projects for the future, so we might want to hodl a bit on this.

[juan-cortes]

If I throw an exception on the checkValidTransaction method, the field that gets the feedback and message is the amount field. I wanted to show the error on a different field but still disable the next button if the validation failed.

  checkValidTransaction: async (a, t) => {
    if (t.memoError) {
      return false
    }
    if (t.amount.isLessThanOrEqualTo(a.balance.plus(t.fee))) {
      return true
    }
    throw new NotEnoughBalance()
  }

I'm not against changing this at all, I just needed a way to throw an error on my own input from the AdvancedOptions without it being linked to the amount field. So with the code in this pr, the validation of an invalid form, failing because of a memo issue, would give us this

If instead of relying on the false case like I'm doing I throw an error if t.memoError I get this sort of validation which is not really true because I have no issue with the value of amount but rather the value of the memo. Might be a better way that I'm failing to see?

[meriadec]

@gre I think we can merge this for now? If needed we can iterate later for error messages precision.

[gre]

we can yes. we need to reiterate around this part for next release so i'll do more testing on these subject anyway. (in context of improving how fees are loaded)