Adding SciToken robots accounts

This MR makes changes to update_user_accounts_from_ligo_ldap.py so that it can now process SciToken robot accounts that are part of group Services:GraceDB:SciTokens:scopes:read:authorized (that is the gracedb.read scope). One has to search the LDAP branch of 'ou=scitoken,ou=robot,dc=ligo,dc=org', see #306.

This MR makes changes to the LdapSciTokenRobotResultProcessor so that it now fully handles robot scitoken users using this logic flow:

1) get all ldap_accounts: (result_data = ldap_connection.perform_query())
for ldap_account in ldap_accounts:
    2) get all attributes (uid and scopes) from ldap_account. (extract_user_attributes())
    3) in get_or_create_user() check if there's an existing account in gracedb:
        Is there an exiting account?
            If yes:
                    .get() gracedb account
            If no:
                    Does the ldap_account have gracedb.read scope?
                            If yes:
                                      create robot user account
                            If no:
                                      do nothing and go to the next ldap_account
    4) in update_user_groups() 
        Does the ldap_account have gracedb.read scope?
            if yes:
                If ldap_account has gracedb.read scope and is in internal_user group: do nothing.
                If ldap_account has gracedb.read scope, is an internal user but not in internal_user group: add gracedb_account to internal_user group.
                If ldap_account has gracedb.read scope, is not an internal user but ldap_account is in internal_user group: remove internal user.
            if no:
                If ldap_account doesn't have gracedb.read scope, is not an internal user but ldap_account is in internal_user group: remove internal user.
    5) save_user()

This should cover all possibilities for new and existing users that are internal users and have the gracedb.read scope or the case where existing users have either the gracedb.read scope removed or are removed from the internal users.

Testing:

Several tests have been run on gracedb-dev2. The first is to delete all scitoken robot accounts from the gracedb database and then run update_user_accounts_from_ligo_ldap.py:

$ python3 manage.py update_user_accounts_from_ligo_ldap robots -v 3
Refreshing users from robots LDAP at 2023-10-23 17:58:17.939888
Created user and ligoldapuser for aframe-scitoken
Adding aframe-scitoken to internal_users
Created user and ligoldapuser for igwnconda-scitoken
Adding igwnconda-scitoken to internal_users
Created user and ligoldapuser for gracedb_test_scitoken
Adding gracedb_test_scitoken to internal_users
Created user and ligoldapuser for cit-summary-pages-scitoken
Adding cit-summary-pages-scitoken to internal_users
Created user and ligoldapuser for lho-summary-pages-scitoken
Adding lho-summary-pages-scitoken to internal_users
Created user and ligoldapuser for llo-summary-pages-scitoken
Adding llo-summary-pages-scitoken to internal_users
Created user and ligoldapuser for production-pe-data-access-scitoken
Adding production-pe-data-access-scitoken to internal_users
Created user and ligoldapuser for production-pe-data-access-osg-scitoken
Adding production-pe-data-access-osg-scitoken to internal_users

The next test was to take an ldap_account (dashboard2-scitoken) without the gracedb.read scope, manually add it to the internal_users group, and then run update_user_accounts_from_ligo_ldap.py again:

$ python3 manage.py update_user_accounts_from_ligo_ldap robots -v 3
Refreshing users from robots LDAP at 2023-10-23 17:29:10.641600
Removing dashboard2-scitoken from internal_users