Rename constructor Proof_level.{None -> No_check}

[georgeee]

Using widely used None for name of constructor lead to an issue when ~proof_level parameter changed its type and compiler left it unnoticed.

Explain how you tested your changes:

• Nightly passes

Checklist:

• Dependency versions are unchanged
  • Notify Velocity team if dependencies must change in CI
• Modified the current draft of release notes with details on what is completed or incomplete within this project
• Document code purpose, how to use it
  • Mention expected invariants, implicit constraints
• Tests were added for the new behavior
  • Document test purpose, significance of failures
  • Test names should reflect their purpose
• All tests pass (CI will check this if you didn't)
• Serialized types are in stable-versioned modules
• Does this close issues? None

[georgeee]

!ci-nightly-me

[georgeee]

!ci-build-me

[georgeee]

!ci-build-me

[svv232]

i believe the nightly is failing because the container name gcr.io/o1labs-192920/mina-daemon:3.0.1-georgeee-proof-level-no-check-a1df77c-bullseye-berkeley is used for both lightnet and the daemon. This was fixed in develop, but not in compatible. This toctou essentially requires you to get lucky to pass CI, and makes retrying in the future break the integration tests.

i am referencing this job https://buildkite.com/o-1-labs-2/mina-end-to-end-nightlies/builds/2557 (which doesn't reference this commit but has similiar changes)

[svv232]

I have attempted to fix: #16106, and will re-run the nightly on that branch.

[svv232]

that branch passes the nightly https://buildkite.com/o-1-labs-2/mina-end-to-end-nightlies/builds/2563#_

I do think it took some massaging. The following observations were made:

• libp2p unit tests occasionally fails because of dropped peers; i am not sure whether this is caused by connection mismanagement, but considering this failure isn't deterministic I would guess something along these lines. The goroutine logic in the unit tests can also be hard to follow at times.

• integration tests occasionally fail with docker swarm issues i.e lack of connections; i'm not sure if this is caused by network load or buildkite agent state, but it definitely makes retrying necessary often.

• fuzzy zkapp unit tests
  I am actually not sure about this one, but i have noticed a few failures in the logging with passing tests regardless. This definately requires further investigation.

[georgeee]

Branch includes a lightnet fix to make nightly pass

[georgeee]

!ci-build-me

[georgeee]

!ci-nightly-me

[coveralls]

coverage: 33.405%. first build
when pulling c830b2d on georgeee/proof-level-no_check
into a89a049 on compatible.