Use optimize for rare edge cases

Consider the following situation.

• The last version of some repository used mirror=False sync policy.
• We now want to sync using mirror=True sync policy.
• Since the mirror policy has changed a full sync will be done in case the change in sync policy results in a change that optimize would skip.
• However, if no change materializes (the repo is already mirrored perfectly), then no new repo version is created, and the new sync policy is not saved on new_version.info.
• If we now sync again using the exact same options as before, we will still do a full sync, even though we could optimize (if pulp_deb could remember that we already tried these sync options without affecting a change).

=> A missed opportunity for further optimization.
However, these circumstances strike me as pretty rare, so I am not sure if it is worth working on.

Note: There may be other similar situations with changed sync options that do not result in a new repo version other than just switching mirror policy.

No file or test is named in the issue. Start by tracing mirror sync-policy handling and how new_version.info records sync options, then identify the existing optimization path. Done means a repeated sync with unchanged results can remember the attempted options and avoid an unnecessary full sync.