Remove the dependency on Guava.

[overcat]

Part of #496

This PR does not include XDR changes, I need to wait for the merge of stellar/xdrgen#168 before initiating a separate XDR-related PR.

---

This PR is almost completed, but before merging it, we need to merge #525 and #527 first and remove com.google.guava:guava:32.1.2-android in build.gradle.

[overcat]

Currently, Java 8 does not have built-in support for Base16 and Base32. Are you inclined to introduce the Apache Commons Codec package or implement it ourselves in the SDK?

Update:
I have added commons-codec to the dependencies list.

[sreuland]

Currently, Java 8 does not have built-in support for Base16 and Base32. Are you inclined to introduce the Apache Commons Codec package or implement it ourselves in the SDK?

Update: I have added commons-codec to the dependencies list.

ok, if interested to avoid the additional dep on commons-codec, can get by with creating a helper method in plain java using String.format - https://www.baeldung.com/java-hexformat#dealing-with-hex-strings-before-java-17

[overcat]

This PR is almost completed. After checking it again tomorrow, I will request a review :-)

[overcat]

commons-codec looks relatively simple and doesn't have a series of dependencies like Guava, so I think it would be great to introduce it, right?

[overcat]

Hi @sreuland, this PR is ready for review, it's big PR 😂

[sreuland]

@overcat , #530 was merged into soroban, looks like need to port latest soroban back to here to finalize. I updated pr with port from latest on soroban - 6c28a2e, tests passing afterwards, looks ready to merge.

[overcat]

@overcat , #530 was merged into soroban, looks like need to port latest soroban back to here to finalize. I updated pr with port from latest on soroban - 6c28a2e, tests passing afterwards, looks ready to merge.

Great, thanks @sreuland.

[overcat]

Hi @sreuland, It seems that the conflict has not been resolved correctly. Please check https://github.com/stellar/java-stellar-sdk/pull/524/files#diff-04e963815abf17aa3afc8545dd7431ba59aa861e57e3a04f53c5c33b82482305L12

Do you mind if I revert this PR and then create a new PR to merge into the soroban branch, and finally squash these three commits on the soroban branch?

[overcat]

I have already fixed this issue in the soroban branch and pushed the code after squashing by using git push origin soroban --force-with-lease

[sreuland]

ok, I had done manual merge of conflicts in SimulateTransactionResponse and SorabanServerTest after porting soroban and looks like chose incorrect direction, thanks for resolving.