horizonclient: update fund method

[poliha]

This PR updates the Fund method that is used to fund new accounts on testnet.
It now uses the internal http client which allows us to set the app headers.
Also it returns TransactionSuccess struct instead of a http response.

Closes #1201

[bartekn]

It looks good however there is one thing I'd like to discuss. We need to figure out which versioning system we want to use. If we want to use semver we should follow it's rules. According to semver two changes of the API in this PR shouldn't be part of 1.0.1:

• New method (Client.Root()) should be part of 1.1.0 (https://semver.org/#spec-item-7).
• Modified API (Client.Fund return type change) should be part of 2.0.0 (https://semver.org/#spec-item-8).

The other option is to actually rename 1.0.0 release to 0.1.0 which is considered an unstable API (https://semver.org/#spec-item-4) and stay at 0.x.x until we're confident that feature set for 1.0.0 is complete and there will be no API breaking changes. However, it's not a good practice.

[poliha]

I think we should use semver, and with that your observations are correct.
As tempting as renaming the release to 0.1.0 is, I think we shouldn't do that because as you said it is not good practice and we already have 1.0 out. I would prefer if we continue to release versions in accordance with semver rules for the changes that we make.

Looping in @tomquisel and @ire-and-curses for their thoughts on this

[poliha]

moved to #1213

[ire-and-curses]

I agree with the points. Given that this is a minor helper method and no one depends on this library yet, can we bend the rule and just increment minor version this time? It seems strange to me to announce to the world a version which is already at 2+.

[bartekn]

It seems strange to me to announce to the world a version which is already at 2+.

We won't announce it yet, but just keep adding features. When there is "enough" to release V2 we can do it.

Given that this is a minor helper method and no one depends on this library yet, can we bend the rule and just increment minor version this time?

I guess we can do this as an exception one time but it would be great to follow the semver from now on. I think that once people will start using it we may want to do some other breaking changes that work better for devs (just guessing, don't have any specific function in mind) so we'll have to start working on that 2.0.0 branch anyway.

[ire-and-curses]

Yeah the reason I say this is that I am finishing up the public blog post today, and we have several minor version changes (e.g. #1198) that we may as well fold in if they're ready before announcing. So I am thinking of incrementing to 1.1 before announcing. I think it will be annoying for users if we change the fund() API very soon after release in a 2.0 release. So I think this next release is a special case. Definitely will do this correctly from now on though.

[bartekn]

Sounds good!