Remove special case in consumer addition/removal proposal handlers

[danwt]

Problem

The handlers unnecessarily (IMO) fork the execution by having two paths

interchain-security/x/ccv/provider/keeper/proposal.go

Lines 30 to 35 in dc19c57

	if !ctx.BlockTime().Before(p.SpawnTime) {
	// lockUbdOnTimeout is set to be false, regardless of what the proposal says, until we can specify and test issues around this use case more thoroughly
	return k.CreateConsumerClient(ctx, p.ChainId, p.InitialHeight, false)
	}
	err := k.SetPendingConsumerAdditionProp(ctx, p)

interchain-security/x/ccv/provider/keeper/proposal.go

Lines 108 to 112 in dc19c57

	if !ctx.BlockTime().Before(p.StopTime) {
	return k.StopConsumerChain(ctx, p.ChainId, false, true)
	}
	k.SetPendingConsumerRemovalProp(ctx, p.ChainId, p.StopTime)

This doubles the number of code paths to be tested and reasoned about for little or no gain because all pending proposals are processed in BeginBlock.

Closing criteria

Remove the 'immediate' branches

interchain-security/x/ccv/provider/keeper/proposal.go

Lines 30 to 33 in dc19c57

	if !ctx.BlockTime().Before(p.SpawnTime) {
	// lockUbdOnTimeout is set to be false, regardless of what the proposal says, until we can specify and test issues around this use case more thoroughly
	return k.CreateConsumerClient(ctx, p.ChainId, p.InitialHeight, false)
	}

TODOs

• Labels have been added for issue
• Issue has been added to the ICS project

Detail

I can see some extremely minor benefit to ux, perhaps if a consumer has to be stopped in 'an emergency' or something.

Priority

This is low priority because everything seems to be working, although there might be odd yet-to-be solved things going on with the proposals (see #438)

[danwt]

cc @MSalopek

[danwt]

An example of this leading to a problem

• Ensure that erroring proposals cannot halt the provider or result in inconsistent state #463