Use memo for arbitrary per-resource payload during operator lifetime

[nolar]

Issue : #112

Description

Since the per-resource in-memory runtime-only containers are already present in the core for internal purposes, it is easy to expose memo kwarg to the handlers, so that the can store arbitrary information or objects about resources.

Same as for the internal use, this should be the objects that are scoped to the operator life time, fully lost on restarts, i.e. not persistent. E.g. threads, tasks, locks, events. Maybe some regular scalars, if their meaning is also scoped to the operator process.

Example:

import kopf

@kopf.on.create('zalando.org', 'v1', 'kopfexamples', cooldown=10)
def create_fn_1(memo, **kwargs):
    print(f'{memo.xyz}')

@kopf.on.create('zalando.org', 'v1', 'kopfexamples')
def create_fn_2(memo, **kwargs):
    memo.xyz = 100

In this example, create_fn_1 raises AttributeError on the 1st attempt, then goes to create_fn_2, and then retries create_fn_1 in 10 seconds with the .xyz field already set.

Both dictionary and object interfaces are supported.

The documentation is intentionally limited — let's first see how it will be used, and what can be the examples.

Types of Changes

• New feature (non-breaking change which adds functionality)

Review

List of tasks the reviewer must do to review the PR

• Tests
• Documentation

[zincr]

🤖 zincr found 0 problems , 0 warnings

✅ Large Commits
✅ Approvals
✅ Specification
✅ Dependency Licensing

[zincr]

🤖 zincr found 1 problem , 0 warnings

❌ Approvals
✅ Large Commits
✅ Specification
✅ Dependency Licensing

Details on how to resolve are provided below

---

Approvals

All proposed changes must be reviewed by project maintainers before they can be merged

Not enough people have approved this pull request - please ensure that 1 additional user, who have not contributed to this pull request approve the changes.

• ✅ Approved by PR author @nolar
• ❌ 1 additional approval needed
   

[dneuhaeuser-zalando]

Doesn't del self[key] call self.__delitem__(key)? Could it be that you intended to implement __delattr__? If not, I do think that implementing the latter would be a good idea for consistency reasons.

[nolar]

Oops. That was __delattr__, of course. Fixed. And few more tests added for deletion of the attrs & keys.