Add AuthCookie for Login with SameSite cookie option

[alexookah]

What

This PR enhances the loginCookie functionality by introducing a new AuthCookie class. This class adds options for configuring the cookie's expiration and SameSite attribute. This should resolve this issue.

Why

Currently, the authentication cookie being set is session-only. This means that when a user closes their browser, they need to re-authenticate upon reopening. This change allows for persistent authentication sessions, reducing the need for frequent logins.

How

This PR introduces the AuthCookie class which replaces the default behavior for setting authentication cookies. The AuthCookie class:

Provides the option to set a custom expiration time for the authentication cookie.
Supports the SameSite attribute for cookies, which enhances security by controlling how cookies are sent with cross-site requests.
Allows users to set the cookie as persistent if they opt for the "remember me" functionality, which is currently not supported by default.

Testing Instructions

Login using a Login provider. Verify cookies and check that SameSite is set to None.

Additional Info

Things to improve: Add options in admin for samesite configuration & domain cookie.

Checklist:

• My code is tested to the best of my abilities.
• My code follows the WordPress Coding Standards.
• My code has proper inline documentation.
• I have added unit tests to verify the code works as intended.
• I included the relevant changes in CHANGELOG.md

[justlevine]

Reviewing from my phone, but issue seems to be method name youre using.

(Feel free to ingore the other feedback if you want, happy to handle myself when I'm implementing docs/tests)

[justlevine]

@alexookah I've rebased this on the current develop branch to fix some issues with ci and testing in WP 6.6. Please make sure to pull --force before committing/pushing any additional changes to this PR.

[coveralls]

coverage: 81.787% (-0.1%) from 81.924%
when pulling 1eed7c4 on alexookah:custom_wp_auth_cookie
into 72936f4 on AxeWP:develop.

[justlevine]

I've begun implementing a more scalable UX that should provide a path forward on this in #141 .

So far, settings have been broken up into different screens, so we can scale horizontally instead of vertically:

Once I clean up the provider settings and conditional logic, we should be able to rebase this paying closer attention to what Login/ Cookie settings should be available on a provider level versus globally.

[justlevine]

Rebased on #141 #144 .

There's still more work to be done on the admin refactor (e.g. stop saving state onChange() ), but that can now be handled independently of this, since the settings registry (PHP) is now fully decoupled from the frontend package.

I think the next step for this PR (beyond the remaining unresolved comments) is to either see if we can more sensibly organize the order of the Access Control settings, or if we should relocate them to a new Cookies tab (or similar).

[justlevine]

Refactored cookie settings to their own group in 7024674

[alexookah]

@justlevine New UI looks awesome!
Whats pending now?

[justlevine]

Integration (WPUnit) tests are the big one. Everything else I believe can be handled iteratively after this is merged/released.

I also need to fix the setting value denouncing before triggering a release, but that's outside the scope of this PR.