[S] Change in coreboot[main]: soc/intel/common/block/cse: Enforce CSE sync with pertinent GBB flag

[Subrata Banik (Code Review)]

Attention is currently required from: Dinesh Gehlot, Paul Menzel, Yu-Ping Wu.

Subrata Banik has posted comments on this change by Dinesh Gehlot. ( https://review.coreboot.org/c/coreboot/+/83686?usp=email )

Change subject: soc/intel/common/block/cse: Enforce CSE sync with pertinent GBB flag
......................................................................

Patch Set 3:

(1 comment)

Commit Message:

https://review.coreboot.org/c/coreboot/+/83686/comment/254ef735_c9afe00e?usp... :
PS2, Line 9: The patch enforces CSE sync when the GBB flag GBB_FLAG_FORCE_CSE_SYNC is
           : enabled and the system is currently booting from the RO section.
> We are intentionally initiating the synchronization process to validate the upstream process, even when the current CSE version matches the CBFS-stored CSE version, hence its `enforcing`.
>
> Please let me know if you would like me to rephrase the description.

We are intentionally initiating the CSE sync process to validate the coreboot update/downgrade logic, even when the current CSE RW version matches the CBFS-stored CSE version, hence its enforcement.

There could be scenarios where CSE updater logic in coreboot has been modified, but for in-field devices, we are not upreving the CSE RW FW. In practice, we are only able to test CSE updater logic when we have different CSE blobs (a version uprev/downgrade). Now assume that the CSE blob has not been changed between months, but the code logic that manages the uprev has been updated. How can we ensure that the modified CSE logic in coreboot will be able to handle any future CSE uprev scenario unless it is tested? This CL introduces a GBB that ensures that we are primarily testing two cases:

1. coreboot CSE update logic, as we modify cse_lite.c much more frequently than we actually uprev the CSE blob

2. The ability to boot to the OS after a successful erase/write/read of the CSE RW partition.

Can we add a detailed commit msg and test steps like this to ensure  reviewers follow what this CL tries to achieve?