Factor out checks for staking's bond & nominate

[emostov]

This is a back port from #10694.

The new functions factored out here will be used to implement a new PoolsInterface:

substrate/frame/staking/src/pallet/impls.rs

Lines 1440 to 1477 in 732c30b

	fn bond_checks(
	stash: &Self::AccountId,
	controller: &Self::AccountId,
	value: Self::Balance,
	_: &Self::AccountId,
	) -> Result<(), DispatchError> {
	Self::do_bond_checks(stash, controller, value)?;
	if frame_system::Pallet::<T>::can_inc_consumer(stash) {
	Ok(())
	} else {
	Err(Error::<T>::BadState.into())
	}
	}
	fn bond(
	stash: Self::AccountId,
	controller: Self::AccountId,
	value: Self::Balance,
	payee: Self::AccountId,
	) -> DispatchResult {
	Self::bond(
	RawOrigin::Signed(stash).into(),
	T::Lookup::unlookup(controller),
	value,
	RewardDestination::Account(payee),
	)
	}
	fn nominate_checks(
	controller: &Self::AccountId,
	targets: Vec<Self::LookupSource>,
	) -> Result<(Self::AccountId, Vec<Self::AccountId>), DispatchError> {
	Self::do_nominate_checks(controller, targets)
	}
	fn unchecked_nominate(stash: &Self::AccountId, targets: Vec<Self::AccountId>) {
	Self::do_unchecked_nominate_writes(stash, targets);
	}

The idea is these checks can be exposed by trait PoolsInterface. Additionally, since the nominate checks map & collect the targets, we avoid redundant memory usage and computation by piping the targets from the check into a write function. The plan is for this nominate write function to also be exposed by the PoolsInterface so the pool can call the check, do some other checks, and then input the targets into the write function.

I still not sure this is the right approach as it makes the PoolsInterface a bit more leaky, so this needs some discussion.

[kianenigma]

should we prefer ensure prefix to be more aligned with the rest of the codebase?

[kianenigma]

Suggested change

	// Initial nominations are considered submitted at era 0. See `Nominations` doc.
	// Initial nominations are considered submitted at era 0. See [`Nomination`]'s doc.

[kianenigma]

looking at your other branch, I am not sure either if this is the right approach, so perhaps not backporting this yet is a good idea.

Fundamentally, why do you need these ensure functions to be exposed? Why can't you just call StakingInterface::nominate, which returns a Result? (at it is already doing, aka. DispatchResult).

[emostov]

As per discussed offline, I am going to look into using transactional TXs instead of added can_/ensure_ type functions, so closing for now