Post-Migration Cleanup: Removal of Redundant Processes and Code Related to Old Stamp Format

[nutrina]

User Story:

As a Passport App developer,
I want to clean up any redundant processes and code after the successful implementation of the new stamp format and writing to ComposeDB,
So that I can maintain a clean and efficient codebase.

Acceptance Criteria

GIVEN the new stamp format has been successfully implemented and has been live for 90 days,
WHEN I review the Passport App codebase,
THEN I should not find any processes or code related to the old stamp format.

Product & Design Links:

Tech Details:

• Remove the on-the-fly conversion of the stamps to the new format.
• Scorer: Drop APIs that are reading & writing stamps in the old format from the ceramic cache.
• AMI: Drop service converting stamps from old to new format, drop the issuance of old stamps, drop the code meant for bringing stamps in the old format on-chain.
• Passport: Delete the old CeramicDatabase class that would read & write from old Ceramic network.

Open Questions:

Are there any dependencies or potential impacts on other parts of the system that we need to consider during the cleanup?

Notes/Assumptions:

The cleanup process should be performed 90 days after the go-live of the new stamp format, as any stamps in the old format would have expired by then.