Implement a way to convert an FSM constraint suffix into an FSM state allowlist

[lgarron]

We convert the prefix constraint into a state, which can be used immediately at the top-level search node:

twips/src/lib/_internal/search/iterative_deepening/iterative_deepening_search.rs

Lines 315 to 321 in 89e14c9

	let initial_state = self
	.apply_optional_fsm_moves(
	CANONICAL_FSM_START_STATE,
	&individual_search_data
	.individual_search_options
	.canonical_fsm_pre_moves,
	)

For the suffix, we actually try applying the moves:

twips/src/lib/_internal/search/iterative_deepening/iterative_deepening_search.rs

Lines 533 to 540 in 89e14c9

	if self
	.apply_optional_fsm_moves(
	current_state,
	&individual_search_data
	.individual_search_options
	.canonical_fsm_post_moves,
	)
	.is_none()

We could instead take every possible state and see which ones allow the suffix to be applied. Those can then either be pre-calculated or can be cached for lookup when calculated during the search.

This work will hopefully also give us a way to replace the pre-move and post-move vectors with something (either data or a dynamic helper) that allows FSM constraints to be easily propagated across phases without manual code. (See this TODO.)

[lgarron]

This work will hopefully also give us a way to replace the pre-move and post-move vectors with something (either data or a dynamic helper) that allows FSM constraints to be easily propagated across phases without manual code. (See this TODO.)

Note that this is also more complicated than it might seem, as different phases do not use compatible FSMs. In fact, they don't even use compatible move sets! In particular, Kociemba phase 2 uses only half moves:

twips/src/lib/scramble/puzzles/two_phase_3x3x3_scramble_finder.rs

Line 190 in cb57043

// TODO: support a way to specify a quantum factor

(This is actually an important reason an automatic mechanism would be quite valuable! This stuff is easy to get wrong, so it would be nice if the correct thing was the automatic thing.)