Track scheduled vs enqueued metrics

[orioldsm]

Fixes a previously incorrect finding that Sidekiq::Context.current[:class].present? would help us differentiate whether or not to categorize a passthrough of a job through the Client middleware as an enqueue.

The more appropriate determining factor is actually the presence of the numeric timestamp typed at field that is passed within the job parameter for scheduled jobs. The presence of at indicates that this job is not being placed on a queue right now, but rather it is being scheduled to be enqueued later at the numeric timestamp value of at.

This change will prepare the Client Middleware to correctly handle the following two ways a worker can perform:

• perform_async: a job is not scheduled and immediately is enqueued with no at field.
• perform_in: a job is scheduled and passed in with an at field for when it should hit the middleware an additional time without the at field to be enqueued.

The other types of performs don't hit the Client Middleware at all, as perform_inline and new.perform cause a job to execute synchronously.

Example job payload when perform_in(1.second) is used by a worker:

{
       "retry" => true,
       "queue" => "some_queue",
       "backtrace" => 10,
       "lock" => :until_executed,
       "on_conflict" => :log,
       "args" => [1],
       "class" => "SomeWorker",
       "jid" => "fee1b8f9a57141629fa03657",
       "created_at" => 1727312692.754786,
       "lock_timeout" => 0,
       "lock_ttl" => 600,
       "lock_prefix" => "uniquejobs",
       "lock_args" => [1],
       "lock_digest" => "uniquejobs:18644d31fbaec54e24fc2253c0180bff",
       "at" => 1727312693.755
}

You can see above that the numeric timestamp value of at is the value of created_at with an additional second added to the timestamp.