Call check_call_orders not only when settlement_price changed

[abitmore]

Actually changing either of these fields in price_feed struct should trigger check_call_orders:

• settlement_price
• maintenance_collateral_ratio

Another field is maximum_short_squeeze_ratio, seems no need to call check_call_orders after it changed, but it's safe to check as well.

[abitmore]

Specifically, these checks are NOT enough:

bitshares-core/libraries/chain/asset_evaluator.cpp

Lines 466 to 470 in 2d0d4bb

	const auto old_feed_price = bdo.current_feed.settlement_price;
	bdo.update_median_feeds( db.head_block_time() );
	// We need to call check_call_orders if the settlement price changes after hardfork core-868-890
	return after_hf_core_868_890 && old_feed_price != bdo.current_feed.settlement_price;

bitshares-core/libraries/chain/db_maint.cpp

Line 923 in 2d0d4bb

bool median_changed = ( old_price != bitasset_data.current_feed.settlement_price );

[abitmore]

Need to change to check like this:

bitshares-core/libraries/chain/asset_evaluator.cpp

Line 716 in 2d0d4bb

if( !(old_feed == bad.current_feed) )

[abitmore]

Question: is it better to fix this directly, or fix with a new hard fork (actually only for testnet)?

[abitmore]

@pmconrad @jmjatlanta please comment.

[jmjatlanta]

What we have added in the latest hardfork is an improvement. I agree that these additional cases should trigger a check_call_orders.

If I'm understanding your question correctly:

A new hardfork check gives us more flexibility at low cost IMHO, and as always, can be removed if nothing triggers.

I defer to you and @pmconrad as to deciding where in the release timeline this fix should be placed.

[abitmore]

Actually this can cause more serious issues, since it may incorrectly skip black swan checks, when combined with changes for BSIP31-34, we won't check for black swan when placing new limit orders after hf (probably a bad decision, too much performance related consideration led to poorer error tolerance), so when a new limit order is placed, collateral ratio of matching call order may be less than 100%... I'm not going to reason the final consequences, anyway, we'll fix this issue before production release, but it's less important (also perhaps no enough time) to make it perfect for testnet (where bad things may or may not happen). @pmconrad what's your opinion?

[pmconrad]

Agree to include the fix now.

[abitmore]

Fixed with #965.