rewrite security.xml
      group_sign_employee is removed
    sign.template:
      decouple "favorited_ids" and permissions
      add "invited_ids" to get read permission of a template
      "invited users", "template access group", "user_id(responsible)", "creator" and "group_sign_manager" can edit template
    sign.request:
      "creator" and "group_sign_manager" can edit the sign.request
      followers, signers, and sender can read the sign.request
    sign.log:
      sign.request's followers, signers, and the sender can read log without IP and geo locations
      group_sign_manager can read all logs with IP and geo locations
    
    before:
    1. the "group_sign_employee" is added from task-2267471.
       But now the only difference between "group_sign_employee" and "group_sign_user" is:
       we only hide "UPLOAD A PDF TO SIGN" button for "group_sign_employee" which actually cannot prevent "group_sign_employee" from owning a template.
       We decide to remove this group.
    2. some rules are redundant and can be removed
    3. the behavior of security becomes contradictory sometimes after adding many features.
       For example a "group_sign_user" can see a sign.request if he is in the "favorited_id" or is a follower.
       But he can read/write/unlink all sign.request.items in the debug mode from Sign -> Configuration -> Signature Requests Items
    4. We protect many models only from UI.
       For example, a "group_sign_user" can only see sign.request if he is in "favorited_ids" or "group_ids"(template access group).
       However, he can read/write all sign.request.items of other users.
       Also sign.request.item.value can be written/unlinked by any user.
    5. the creator/responsible of a template may lose his read/write permission of his records by removing himself from "invited users"(or unclick "favorite" star button).
       The creator of sign.request may lose his read/write permission of his sign.reqeust by removing himself from the follower list.
       These actions cannot undo.
       And when they lose the read permission, our current framework will immediately trigger an access error, which is confusing and not good for UX.
 
task-2618406