Support Expiration Lifecycle

[KirillovDenis]

Should we support lifecycle? https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html I suppose there are some restriction (if we want to support it):

• Support only Expiration actions (available Expiration actions and Transition actions) because s3-gw can not handle storage classes (or it will be?)
• Expiration actions will only work in the context of the gateway, and the gateway must store the user's credentials

[realloc]

We can't use NeoFS exipration attributes here, because in S3 the object lifecycle/expiration is mutable.

[alexvanin]

Good use case for serverless functions to handle actions after expiration.

[KirillovDenis]

Blocked by https://github.com/nspcc-dev/neofs-api/issues/226

[KirillovDenis]

Still there are some questions:

Access rights.

We need a bearer token to be able to delete an object after appropriate tick happens. We can store this info (address of the object with access box) in user-defined tick data https://github.com/nspcc-dev/neofs-api/issues/226)

Where we should store expiration object info:

1. In the version tree
   • Pros: One request to tree service during head object request.
   • Cons: Complicated logic to retrieve expiration info because the node in tree will be sibling for object version nodes
2. In the expiration tree
   • Pros: Simple logic
   • Cons: Additional request to the tree service on every head/get object request
3. Don't store expiration info at all and compute it on every request using cached lifecycle configuration
   • Pros: There is not extra request to the tree service
   • Cons: More CPU intensive every head/get object request

It seems we have to extend object/expiration info that stored in tree service by object size to be able to get rid of head request.