Feature/plmc 412 on initialize benchmarks

[JuaniRios]

What?

Add the benchmarks for all the functions called inside on_initialize. Make them as accurate as possible as in #148

Why?

on_initialize needs to know the exact weight consumed to let the rest of the extrinsics execute.
If it's inaccurate, we risk never producing blocks in the worst case, or consuming all the block space and having no space for extrinsics.

How?

Same as #148

Testing?

Same as #148

Screenshots (optional)

Anything Else?

• We're currently discussing if it makes sense to remove the on_initialize in favor of extrinsics that any user can call, and add some incentive for them to do it.
• If we don't do that, then we should make it possible to call the project transitions from root origin in case one of these functions fails.

[vstam1]

Logic looks good to me with a couple of comments. One more general comment would be around all the unwraps in instantiator/benchmarks/tests. Might be good to handle them (where making sense) more gracefully. Had some tests failing in previous PR with big panic around unwrap on error. Better to handle it properly.

[lrazovic]

Great job, we're getting closer and closer to having accurate weights for every possible branch of the pallet!

In addition to Just's comments, I would like clarification on the use of unwrap_or_default in the hook. Once that's clear, we can merge.

[JuaniRios]

Logic looks good to me with a couple of comments. One more general comment would be around all the unwraps in instantiator/benchmarks/tests. Might be good to handle them (where making sense) more gracefully. Had some tests failing in previous PR with big panic around unwrap on error. Better to handle it properly.

What would you suggest is a better way to handle it?
IMO we want the code to panic with the error if its compiled only when testing.
Otherwise chasing the error might be harder

[vstam1]

Logic looks good to me with a couple of comments. One more general comment would be around all the unwraps in instantiator/benchmarks/tests. Might be good to handle them (where making sense) more gracefully. Had some tests failing in previous PR with big panic around unwrap on error. Better to handle it properly.

What would you suggest is a better way to handle it? IMO we want the code to panic with the error if its compiled only when testing. Otherwise chasing the error might be harder

Could do "expect("some useful error message")" instead of unwrap? Could also do assert!(result.is_ok()).

[JuaniRios]

Logic looks good to me with a couple of comments. One more general comment would be around all the unwraps in instantiator/benchmarks/tests. Might be good to handle them (where making sense) more gracefully. Had some tests failing in previous PR with big panic around unwrap on error. Better to handle it properly.

What would you suggest is a better way to handle it? IMO we want the code to panic with the error if its compiled only when testing. Otherwise chasing the error might be harder

Could do "expect("some useful error message")" instead of unwrap? Could also do assert!(result.is_ok()).

assert_ok would do the same as unwrap, in that it will panic with the error type. We could do a new PR where we replace the unwraps with expects explaining the possible causes for that panic. But lets not do it here