add liquidation flag

[nialexsan]

add liquidate flag

[sisyphusSmiling]

np: my preference would be liquidate

[sisyphusSmiling]

Similar to feedback on another implementation PR, I think we may be overloading the word "liquidate" which has its own connotations in DeFi such as lending protocols and it's likely that most Sources won't relate to these use cases.

Also, I worry that by adding the Bool to minimumAvailable() we may be polluting the Source interface with concerns unrelated to it's intended scope and/or introducing a leaky abstraction with this parameter.

Most all connector implementations so far would simply ignore the parameter altogether. And so most callers would pass an arbitrary true or false unless the configured connector is known to implement it which IMO defeats the purpose of the param and could also harm composability. For instance, if I design a connector that only returns the fully available balance if liquidate is true and some other common connector hardcodes false, it becomes detrimental for strategies to combine the two connectors.

I'm presenting some alternatives below for consideration:

• Add a connector interface as a sort of "extension" to a Source, say "Liquidator" that has methods liquidationAmount(): UFix64 and liquidate(data: AnyStruct?): @{FungibleToken.Vault}. This maintains the philosophical separation of concerns inherent to DeFi Actions and still enables the functionality for use cases that demand two types of balances. I think it would be safe for this connector to extend Source.
• Add Source.maximumAvailable(): UFix64 method which IMO more explicitly separates the two routes. Maybe it's a semantic hangup on my end with liquidate and stylistic preference to avoid an interface param that's likely to be ignored, but I think this makes behavior more apparent to callers.

My preference would be the second option, primarily because I think there is a use case for a Liquidator and I'd hate to introduce and finalize a connector's interface before we consider those beyond our initial one.

[sisyphusSmiling]

Suggested change

	/// Returns an estimate of how much of the associated Vault Type can be provided by this Source
	/// Returns an estimate of how much of the associated Vault Type can be provided by this Source
	/// with a flag that may be useful for denoting a caller wants the fully available balance the Source
	/// can provide.

[nialexsan]

closed in favour of another approaches