Archive: migrate non-nullable zkapp state as well

[glyh]

This PR added migration for non-nullable zkapp state table.

TODO:

• fix issue that failed commands lead to succeeded result

previous: #17826

[dkijania]

Can you reason why 0 not null?

[glyh]

See https://github.com/MinaProtocol/MIPs/blob/main/MIPS/mip-0007-increase-state-size-limit.md#backwards-compatibility

[glyh]

MIP explicitly specify we should use 0 as polyfill.

[cjjdespres]

One thing that zkapp_states_nullable seems to be used for is constructing account updates:

mina/src/app/archive/lib/load_data.ml

Lines 512 to 527 in 90ff48c

	let%bind state =
	let%bind elements =
	query_db ~f:(fun db ->
	Processor.Zkapp_states_nullable.load db state_id )
	in
	let elements = Pickles_types.Vector.to_list elements in
	let%map fields =
	Deferred.List.map elements ~f:(fun id_opt ->
	Option.value_map id_opt ~default:(return None) ~f:(fun id ->
	let%map field_str =
	query_db ~f:(fun db -> Processor.Zkapp_field.load db id)
	in
	Some (Zkapp_basic.F.of_string field_str) ) )
	in
	List.map fields ~f:Or_ignore.of_option |> Zkapp_state.V.of_list_exn
	in

That state contains a vector of F.t Or_ignore.t - the field elements are allowed to be absent, I think because the update might only affect the state at certain indices.

Should we be adding 0 as a value to the update in that case? If this is only used for updates then null seems more correct.

[glyh]

^ I assume this comment is for PR #17826