fix: Use same client_key for Actor created request_queue and improve its metadata estimation

[Pijukatel]

Description

• When creating RequestQueue from Actor on the platform or with force_cloud=True the client_key should be set to run_id. This ensures:
  • Each API call of the same RequestQueue instance that is using ApifyRequestQueueClient will be done with the same client_key and thus in metadata had_multiple_clients=False
  • Multiple instances of RequestQueue created by Actor.open_request_queue() on the platform share the same client_key and thus in metadata had_multiple_clients=False
  • On the platform, since the client_key is set to run_id, it remains the same for resurrected or migrated run, and thus in metadata had_multiple_clients=False
• Improved reliability of had_multiple_clients allows better estimation of RequestQueue metadata.
  • When had_multiple_clients=False, it is possible to trust local estimation of the metadata.
  • When had_multiple_clients=True, local estimation is no longer valid, but still can, in some cases, improve estimation by being ahead of the delayed API update of the metadata. Therefore API-based metadata are fused with local metadata estimation to produce as good estimation as we can.
• ApifyRequestQueueClient init changed to properly initialize from full metadata - to enable more reliable metadata after migration/resurrection or when using existing RequestQueue
• During _list_head, if there is a call to API, use the available had_multiple_clients to update local estimation of this value. This is a cheap way of knowing if there is another client or not without the need to make a new API call. _list_head is called frequently enough to make the local estimation of had_multiple_clients decently good.

Issues

• Closes: Actor should use same client_key for all ApifyRequestQueue client calls #536

Testing

• New tests added

[Pijukatel]

As of now, the test_request_queue_not_had_multiple_clients_platform_resurrection will fail due to an already acknowledged bug on the platform, but that should be fixed in the near future.

In develop branch: https://github.com/apify/apify-worker/pull/1470

[Pijukatel]

The necessary fix on the platform was merged to master, and it is working now.

[vdusek]

Looks good, let's see how it behaves...

I'm just not sure about the feat: 🙂, maybe rather a fix?