chore: contract class log refactor follow up

[MirandaWood]

Closes #12325

• Move the hashing of the contract class log to the oracle (as it was previously when we used sha hashing), since we constrain its correctness in the base rollup. (We don't want this!)
• Rename oracle methods? (I don't know much about oracle best practices)
• Move validate_and_silo_contract_class_log functionality and possibly rename.
• Remove the blob check in data_retrieval now that we have no calldata.

---

TODO: is this comment still correct? NB from before the cc log PR, the only thing that has changed is we get a poseidon hash from the oracle (rather than SHA) and we constrain it in the rollup (rather than L1).

        // The log preimage is too large for the hash to compile (16,200 fields, 518,400 bytes), so we do this via a
        // specialized oracle.
        // A malicious oracle cannot force us to use an incorrect bytecode:
        // - Contract class -> we will commit to the packed bytecode (currently a TODO)
        // - Private function -> we provide a membership proof
        // - Unconstrained function -> we provide a membership proof
        // However, the sequencer will be required to know a contract's preimage if it is called and the sequencer
        // cannot prove non-registration. Therefore, it is possible that a malicious oracle might prevent sequencers
        // from including transactions with calls to certain badly-broadcasted contracts.
        // TODO(#8978): review correctness

[MirandaWood]

After removing this check, we no longer check the blobHashes (part of EthBlobEvaluationInputs) which are an input to getBlockFromRollupTx. These originally come from L1 events as far I can see, so I think are safe, but can just be extracted in this fn rather than passed around the place. Maybe this is preferable?

[LeilaWang]

I think I just remember why we decided to hash in the circuit...
If I tweak the oracle to return a log_hash that's for a completely different contract, and submit that along with the tx, all the checks will still pass. But because the log_hash is not used in computing the class id, the class id will be associated with a wrong artifact. This will prevent people from calling that contract unless the correct artifact is provided using some non-standard codepath.

[MirandaWood]

Aaah that was it. So even though in the base rollup we must provide the 'wrong' contract class log preimage to match this tweaked log_hash, we can still broadcast a mismatched class id?

[LeilaWang]

Just checked the code again, we don't have an api for fetching contract data by class id, the class id is separated from the log. But users will only be able to fetch the wrong contract data from the log store. And because it's not registered they will have to register it again to start using it.

As for the correct contract, its class id was registered and the nullifier being emitted, so it can't be registered and broadcasted with the correct log again. The contract data will have to be stored in the log store or provided to the pxe manually if wanting to use that contract.

[MirandaWood]

Makes sense! I will revert the part that hashes in the oracle