Better fee calculation

[LimpidCrypto]

High Level Overview of Change

Use of better fee calculation formula but keep supporting the current. The current way is marked as deprecated.
Add info to the docstring that get_fee is returning drops.

Context of Change

As proposed in #330 and #352

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• Documentation Updates

Test Plan

None

[LimpidCrypto]

If this PR should be merged should I add the changes as 'Added' or 'Fixed' in the CHANGELOG.md?

[LimpidCrypto]

I am a little confused how the integration tests work. Every rippled api request you make is basically made via localhost, right? Why does the result of the fee method not include "max_queue_size"?
@JST5000 why does the fee_type has to be "open" as default to be backwards compatible? In my opinion the default fee_type should be dynamically calculated fee.

Thank you :) You guys already taught me so much 🙏

[JST5000]

@JST5000 why does the fee_type has to be "open" as default to be backwards compatible? In my opinion the default fee_type should be dynamically calculated fee.

My main worry with that is if updating xrpl.js version changes how much money people spend on fees without any warning. While I do think the dynamic calculation is better, I don't want to increase how much people are paying without their explicit opt-in. So my thought was that it'd be backwards compatible to keep the calculations the same unless folks opt-in to the better calculations.

That being said, I haven't done the math to see if the new calculations are higher than the previous calculations. If they're always lower when the queue is empty, then I think it makes sense to just use the better fee calculation as the default.

[LimpidCrypto]

@JST5000 why does the fee_type has to be "open" as default to be backwards compatible? In my opinion the default fee_type should be dynamically calculated fee.

My main worry with that is if updating xrpl.js version changes how much money people spend on fees without any warning. While I do think the dynamic calculation is better, I don't want to increase how much people are paying without their explicit opt-in. So my thought was that it'd be backwards compatible to keep the calculations the same unless folks opt-in to the better calculations.

That being said, I haven't done the math to see if the new calculations are higher than the previous calculations. If they're always lower when the queue is empty, then I think it makes sense to just use the better fee calculation as the default.

Ah I did not think about that. I agree to you, the "dynamic" option should not be the default to prevent unwanted higher fees :)

[JST5000]

LGTM :)

[mvadari]

Left a couple notes on where to leave some additional comments for better code readability, looks good otherwise