Remove deprecated code in Pyramid 2.0

[mattiaverga]

This change will remove calls to deprecated methods in Pyramid 2.0. Note that will also make Bodhi require Pyramid > 2.0 as the new authentication policies method should not be available in versions before 2.0 (at least, I have not found them in Pyramid's 1.9 docs).

[mattiaverga]

I can't understand why Integration tests on Rawhide and F38 are still failing. When the bodhi-client tries to perform any action which requires authentication it gets a permission denied.

I thought it was something related to Pyramid 2.0, but even with the new security policy in place it still fails. Moreover, after upgrading staging Bodhi base image to Fedora 38, so that now uses Pyramid 2.0, the bodhi-client seems to work fine there. So I think there's something wrong in our Integration tests setup, but I'm unable to find what.

[mattiaverga]

Thanks @abompard for the fix of F38 Integration tests.
So, looks like the current bodhi 7.2.0 is indeed compatible with Pyramid 2.0. This change is therefore getting lower priority as we can safely upgrade prod to F38.

I'll keep this waiting until someone find time to do a full security review, as I think I've just updated the existing Pyramid security settings to the new format, but I may have missed something.
In the meantime, I've merged this PR into staging and deployed, so it can also be tested there (so far it looks good, but I'm in provenpackager group, so it's hard to get authorization tested properly).

[AdamWill]

Did this break the authtkt.timeout feature? AFAICS, before this commit, that was handled by the upstream pyramid.authentication.AuthTktAuthenticationPolicy class that the old code used; but this code replaced that with the new BodhiSecurityPolicy class, which takes max_age as an arg but never does anything with it. So AFAICS the setting does nothing, and possibly Bodhi cookies no longer ever expire?

edit: there is some behind-the-scenes stuff there, because we're implementing an upstream "security policy" API and calling upstream's set_security_policy on it, but having taken a look at the upstream code I don't see that it's doing any kind of black magic to use this max_age value. I don't see how it could anyway, since we call it on an instance of BodhiSecurityPolicy, which means I don't think the upstream code would be able to get an arg that was passed when instantiating it but not saved anywhere in the instance...

[mattiaverga]

yeah, I forgot to pass the arguments to AuthTktCookieHelper...

[mattiaverga]

#5572 should fix it