Add non-breaking muxed account support to fee-bump transactions.

[Shaptic]

To avoid a breaking change, I've introduced a way to set the source of a fee-bump transaction via account strings (in both G... and M... form). To enable proper muxed accounts, you pass withMuxing: true as the last parameter of TransactionBuilder.buildFeeBumpTransaction() just like everywhere else to explicitly opt-in. Namely,

const feeTx = StellarBase.TransactionBuilder.buildFeeBumpTransaction(
  feeSourceMAddress,
  bumpedFee,
  innerTx,
  networkPassphrase,
  true // optionally parses the source as a true muxed address
);

[leighmcculloch]

A couple questions and thoughts shared inline.

[leighmcculloch]

If we need this method can we rename this to createdMuxedAccount? See #433 for why.

However, I think this function confusing. You can't create a muxed account that multiplexes another muxed account. The following code, although verbose, seems much clearer. Is there a reason we can't use it? or a reason we need to be able to create muxed accounts from muxed accounts?

muxedAccount.baseAccount().createMuxedAccount(id)

[Shaptic]

Though I completely agree that it's odd to have this method on this object, I added it to MuxedAccount so that there was "interface" compatibility with Account. And 👍 for the rename, though unfortunate that it wasn't noted at its introduction.

[leighmcculloch]

What is driving the need for this interface compatibility? I don't see anything new calling createSubaccount in this PR.

[Shaptic]

There's no true need (especially since nobody is using muxed accounts); I just had it in mind after stellar/js-stellar-sdk#653.

[leighmcculloch]

Ah, interesting. In this case, I don't think all accounts should have this capability.

[Shaptic]

I agree in theory, but then you cannot use MuxedAccount abstraction where Account is allowed, yet the two should be largely interchangeable. Fixing this imo fundamentally requires a bigger change (see this comment, where createSubaccount exists only on the non-interface), but that's out of scope here, so for now I think making muxed accounts "quack like an Account" is a reasonable measure.

[leighmcculloch]

Got it. Thanks for explaining.

For my own understanding, which is limited here, is there no way in JavaScript/TypeScript to specify an interface type that provides a set of functions, so AccountResponse and MuxedAccount don't always have to have the exact same function set as Account, but rather there could be some interface Account that is a common subset that doesn't include createSubaccount?

[Shaptic]

You're essentially describing exactly what I want: an interface that covers the common subset of functionality across AccountResponse, MuxedAccount, and Account. This would involve replacing everywhere that says Account (an object) which used to act as said "common subset" with some new interface.

[leighmcculloch]

On a final pass I noticed a function below that has a confusing name. I defer to you on it though. Otherwise the PR looks good.

[leighmcculloch]

The name of this function is a little confusing. Often functions named parseX are understood to "parse X". In this case the function is named parseBaseAddress but what it does is "parse an M address".

I think it would be easier to understand the intent of this function if it was named parseMuxedAddress and it returned all the components of a muxed address. I thought we would have had something like this already, but I guess we don't?

[Shaptic]

I see what you're saying. We do have that: MuxedAccount.fromAddress, but doing M -> G strings becomes unwieldy:

const muxed = new MuxedAccount.fromAddress(mAddress, '0');
const gAddress = muxed.baseAccount().accountId();

(see cfc6df0). How about extract over parse, @leighmcculloch? e.g.

const gAddress = MuxedAccount.extractBaseAddress(mAddress);

[Shaptic]

Closes #422