Consider tracking candidate enactment weight in a weight only function

[emostov]

Right now the path the weight gets bubbled up is enact_candidate -> update_pending_availability_and_get_freed_cores -> process_bitfields. In enact_candidate we go through and track the actual weights consumed (opposed to the worst case estimates we use prior).

With the current function having a separate weight only function would be tricky and require some duplicate logic. Basically we would need to duplicate some of the logic that executes here: https://github.com/paritytech/polkadot/blob/888162259348c7fa3e9ad7454e8056235565efa6/runtime/parachains/src/inclusion/mod.rs#L370-L402 . At the moment we are actually modifying storage right there, so we essentially would need to first get the weight of enacting candidates without side effects and then call update_pending_availability_and_get_freed_cores, which would duplicate the filtering logic but actually enact the candidate and write to storage

In an enact_candidate_weight function we would need to take the weight calculations done within these calls https://github.com/paritytech/polkadot/blob/888162259348c7fa3e9ad7454e8056235565efa6/runtime/parachains/src/inclusion/mod.rs#L748-L772 and abstract them to their own weight only functions

While I see the general design merit of having the weight tracked by weight only functions - in this particular case there is a lot of branching logic to determine how much weight actually gets used and duplicating much of that logic in the weight only functions since harder to keep track of then tracking the weight as the actual execution takes place.

Originally posted by @emostov in paritytech/polkadot#4172 (comment)