Use utc times for jids

[dwoz]

What does this PR do?

Porting #51126 to master, instead of #54585.

Using utc for jid's but not making it optional.

See issue #33309

Tests written?

Yes

Commits signed with GPG?

Yes

[terminalmage]

This is a pretty significant change, but I don't see it mentioned in the release notes for neon. Seems like something we should mention.

[waynew]

That's a great point @terminalmage - @dwoz this should also go in the CHANGELOG.md, right?

[terminalmage]

Yeah, it should definitely be documented, but I still feel pretty uneasy about this. Not everyone is UTC minus some offset. The ones east of UTC will see their JIDs appear to travel back in time, and I'm wondering what sort of issues that will cause. Seems like something that should be put on a path where it first has to be explicitly enabled (and warned on startup if not enabled), before making it the new normal.

[waynew]

I'm not familiar with the Salt internals around JIDs, nor the documentation (i.e. what guarantees, if any do we make around JIDs? What implicit assumptions do people have around JIDs).

Of course, everyone already should be using UTC, but having suffered through servers on America/New_York, I know not everyone has the fortune of living with best practices.

Then the other question is what is the practical effect. Will it just be hard to find jobs for N hours? Will they just appear out-of-order in list_jobs? Or will it cause data-loss or is there a potential for salt to explode when two JIDs have an identical timestamp?

I understand the reasoning behind not making it optional (there should be one-- and preferably one --obvious way to do it), and can support that decision. I suppose worst case what we could do is have a flag for one release and then remove it later 🤷‍♂

[terminalmage]

Well, given that they are date-based, they do convey when the job was run. That alone is enough for people to build process around them.

This change just has the feel of something that isn't fully-baked, and an example of how ensuring there is test coverage for a change doesn't necessarily inspire confidence that it won't introduce instability.