Introduce PoRepConfig::new_groth16()

[vmx]

Description

At a lot of places the PoRepConfig struct is created directly which almost always follows a pattern similar to:

let config = PoRepConfig {
    sector_size: SectorSize(SECTOR_SIZE_32_GIB),
    partitions: PoRepProofPartitions(
        *POREP_PARTITIONS
            .read()
            .expect("POREP_PARTITIONS poisoned")
            .get(&SECTOR_SIZE_32_GIB)
            .expect("unknown sector size") as usize,
    ),
    porep_id,
    api_version: ApiVersion::V1_1_0,
};

Instead introduce a PoRepConfig::new_groth16() which could look like this:

let config = PoRepConfig::new_groth16(SECTOR_SIZE_32_GIB, porep_id, ApiVersion::V1_1_0)

The reson for naming it new_groth16 and not just new is, that the Halo2 work introduces PoRepConfig::new_halo2.

Acceptance criteria

PoRepConfig::new_groth16() is used everywhere where currently the PoRepConfig struct is constructed directly.

Risks + pitfalls

I can't think of any.

Where to begin

Introduce PoRepConfig::new_groth16() and use it everywhere where currently the PoRepConfig is used directly.

[DrPeterVanNostrand]

I totally agree. Using constructors would prevent production proofs from being configured with incorrect setup values via struct literals.

[0xpwnstar]

/assign
I would like to work on this.