Add advisory_lock utility from AWX

[AlanCoding]

This migrates advisory_lock from AWX to DAB. This is similar in spirit to #660

Importantly, I went the route of not adding a new dependency, because there was only a single method from the library we were using, and I'm pretty confident that the MIT license lets you do whatever you want. In doing this, I deleted the use of six for python2 compatibility which further reduced the complexity of the code I ported.

Additionally requested reviewers @Alex-Izquierdo @TheRealHaoLiu

[AlanCoding]

@TheRealHaoLiu I was really uncomfortable with this lock_session_timeout_milliseconds when it went into AWX. Historically, we have accumulated untestable code, and then gotten issues reported due to some esoteric circumstance, and gotten into a pickle about how or if we will address it.

Here, this is offering true functional testing. It sets the timeout for the current session and actually watches it time out.

I would like to convert AWX to run checks with postgres, but now is not the time for that. For this overused / abused utility in AWX, holding it to the higher code quality standard in DAB is a good idea, particularly since I'm basically saying we should reuse it in eda-server.

[john-westcott-iv]

It might be nice to have vendor specific files in ansible_base/lib/utils/db i.e. something for postgres/mssql/sqlite and then the db.py would have "Generic methods" which would check the vendor and then call items from the DB specific files.

[tznamena]

Can we add some comments here to explain the logic?

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
83.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[AlanCoding]

It might be nice to have vendor specific files in ansible_base/lib/utils/db i.e. something for postgres/mssql/sqlite

Maybe sometime, I just don't feel like we're really there yet. AWX has probably the most postgres-specific code, and it's just lying around scatter-shot.

It might be nice to attempt sqlite solution, probably like this:

https://stackoverflow.com/questions/6931342/system-wide-mutex-in-python-on-linux

class Locker:
    def __enter__ (self):
        self.fp = open("./lockfile.lck")
        fcntl.flock(self.fp.fileno(), fcntl.LOCK_EX)

    def __exit__ (self, _type, value, tb):
        fcntl.flock(self.fp.fileno(), fcntl.LOCK_UN)
        self.fp.close()

Then that would share a lot of feature and not share a lot of features. So then you have a lot of param handling logic to error if it's 1 vendor and not another. Definitely going in the opposite direction of django-pglocks where this comes from. And I do think that would be good for when we introduce a sqlite version, but that just seems too arbitrary and premature until we're at that point.