Added validation around department_id in API patch request

[marcusmoore]

Description

This PR simply adds the smallest amount of validation around the department_id field when sending an API PATCH request for a user. It was pointed out that sending

'department_id' => ['id' => 1]`

resulted in a success message but didn't actually a change. This is because the endpoint actually needs this format

'department_id' => 1

I just added a validation rule that says the department_id, if provided, needs to exist in the departments table.

---

I started to go down the path of testing validation for all inputs but decided to keep it simple and focused in this PR.

One thing I noticed is that even though our docs say two_factor_enrolled, and two_factor_optin can be updated via this endpoint those properties aren't in the User model's fillable array so changes are not applied. I think the docs should be updated to remove those fields right?

Type of change

• Bug fix (non-breaking change which fixes an issue)

[what-the-diff]

PR Summary

• Enhancements to User Input Validations
  We've included a rule to validate the department_id provided while saving user-related details. This ensures that we maintain data integrity and the system works accurately.

• Improved User Update Functionality Testing
  A new suite of tests has been added to evaluate the user update functionality via patch request. We're now rigorously testing various user attributes such as personal info (first name, last name, username, password, email), professional details (permissions, phone, job title, manager, and employee number), user preferences (notes), organization details (company, department, location, remote status, groups), and timeline details (VIP status, start and end date). This exhaustive testing will ensure a robust and error-free user update function.

[snipe]

Yeah, I don't think we want those fields to be fillable