feat: added a 15 days storage expiration for stx info

[vr16x]

No description provided.

[fichiokaku]

createQuote sets ttl on quote:* and user-op:*:data, but follow-up updates mostly call updateUserOpCustomFields, which only EXPIREs user-op:*:custom-fields.

so the :data (and quote) keys keep the original countdown from quote creation, while custom-fields can be extended on every update — possible mismatch or short-lived data with longer-lived custom-fields, depending on traffic.

worth deciding explicitly is that ok? or should we refresh ttl on the related keys in the same code paths (if we have the keys in context)?

[vr16x]

createQuote sets ttl on quote:* and user-op:*:data, but follow-up updates mostly call updateUserOpCustomFields, which only EXPIREs user-op:*:custom-fields.

so the :data (and quote) keys keep the original countdown from quote creation, while custom-fields can be extended on every update — possible mismatch or short-lived data with longer-lived custom-fields, depending on traffic.

worth deciding explicitly is that ok? or should we refresh ttl on the related keys in the same code paths (if we have the keys in context)?

Really a good question. This is not a problem for us until the initial 15 days and we assume the data pipelines will complete the job within this duration.

Once after this, the only place where those keys are used is from the explorer endpoint which initially checks if quote is there or not. 100% of the time, if the quote is expired, the API will throw an error and never attempts to consume those custom fields even if they have extended expiration time