fix: Unify Actor context manager with init & exit methods

[vdusek]

Description

To align the behavior between the two possible approaches of using an Actor - as a context manager or by explicitly calling init/exit/fail - the following changes were implemented:

• The Actor's arguments (exit_code, status_message, event_listeners_timeout, cleanup_timeout) were added to the Actor.__init__ as well.
• exit_code and status_message are now public properties with setters, allowing them to be updated within a context manager block in response to error conditions.
• The previous approach of calling __aenter__ from init and __aexit__ from exit was reversed, ensuring fewer inconsistencies for future changes (since __aenter__ and __aexit__ have a fixed number of arguments).

Other changes:

• Related docstrings were updated.
• The ordering of methods in the Actor was adjusted (see ruff issue #2425).
• The interface of init, exit, and fail remains unchanged.

Issues

• Closes: Unify Actor's context manager with manual init/exit methods #598

Testing

• The current test set cover the changes.

[Pijukatel]

Am not sure about this. What about this scenario?

...
async with Actor(...):
    await Actor.fail(exit_code=1, status_message='This is a test message')

This used to work before, but now it will try to call __aexit__ twice

[vdusek]

IMO that scenario is a misuse. You've got 2 approaches and you should choose one of them. Not combining them.

[B4nan]

People can use Actor.fail (as well as Actor.exit) as part of their code, even in the request handler, so I wouldn't call that a misuse really. They might want to quit prematurely on purpose, the method is not always supposed to be at the very end of the main script. In JS, it does process.exit so it quits the process completely, so you won't fall into this, the top level Actor.exit wouldn't be called if that happens.

Can we keep a flag to know the exit method was already called, and skip the duplicated logic that would be otherwise produced by the context manager?

[Pijukatel]

I added one test. We can decide whether it is an allowed use case that should be supported or a misuse.
a03b3f1

[janbuchar]

Judging by https://github.com/apify/apify-sdk-python/pull/600/files#diff-807ba3710b8cdf01f23374c98d85a91075d4b602c8c4a3b46ddb64696b16987d I suppose the point raised by @Pijukatel has been resolved?

[vdusek]

If you mean this:

Am not sure about this. What about this scenario?

...
async with Actor(...):
    await Actor.fail(exit_code=1, status_message='This is a test message')

This used to work before, but now it will try to call aexit twice

Then yes, this is a valid scenario (we have the _is_exiting flag).

[janbuchar]

I usually prefer "inlining" the constants to avoid tautological tests. Not a hill to die on in this case, just saying