DX: Allowing null for fee and flatfee in Long and Integer builder methods.

[subhakundu]

This PR contains two changes related to this issue.

1. Allowing null for fee and flatfee in Long and Integer builder methods.
2. Adding unit test for testing behaviour of transaction builder if fee and flatfee is null. (Allow TransactionBuilder to accept null for fee  #523)

Continuation of discussion here, I think we do not need to add check to null out flatfee if fee is set and vice versa. The builder logic goes like this (code)

1. If fee and flatfee are set, we throw an exception. Two values cannot be present in same transaction.
2. If fee and flatfee are null, we set fee to minimum value i.e., 1000 Algos (code). I hope I am using right terminologies. Please pardon my mistakes.
3. If fee is not null, we ignore flatfee altogether. If fee is set as null after setting passed fee value, we set fee in the transaction to the minimum value (1000 Algos).
4. If flatfee is null, fee is set to flatfee in the transaction. This is the case where flatfee is used if fee is null.

I have added a unit test to check various scenarios. If not needed, I can remove it. But I believe it will help document different scenarios in better manner. Please let me know your suggestions and concerns.

I have tested the code by running mvn package and mvn clean test locally.

[CLAassistant]

All committers have signed the CLA.

[jannotti]

Thank you! I'm willing to take the PR as is (once we figure out why the integration tests fail) because it's better than what we had.

But I did not follow your reasoning about why you don't think we should set fee to null when flatFee() is called with a non-null argument and vice versa. The original request for this PR was because someone was calling

b.suggestedParmams(sp)
// set a flat fee instead of taking the recommended fee per byte
b.flatFee(xxx)

and getting a failure because fee was still set to a non-null value. fee was set by suggestedParams, and flatFee was set in an attempt to override the suggestion.

So that person had to use

b.suggestedParmams(sp)
// set a flat fee instead of taking the recommended fee per byte
b.flatFee(xxx)
b.fee((BigInteger)null) // b.fee((Integer)null) doesn't work, causes NPE

They found that untidy, and worried it would change some day. So now, with your change, they can use b.fee((Integer)null) or b.fee((Long)null). But that's still not very tidy!

I think they really ought to be able to use the original code, that simply calls flatFee to override the suggestion. For that to work, the flatFee method must set the flatFee field and null out the fee field. Otherwise, we are in the situation you labeled 1 and we get an exception.

It seems proper to me that when two fields cannot be used at the same time, they should null the other field if they are set. (Of course, they should not null out the other field if they are set to null.)

[subhakundu]

Sure. Let me check once again. I will get back with another revision.