The SimperiumCollaboratorsRepository now has a dependency for
Bucket<Note>, thus, all tests that use the instance directly had to be
updated.

Given that notes are synchronized across different devices, there may
be the case in which a user will try to get the collaborators of a note
that was deleted or is in the trash. For those cases, we cannot add
collaborators.

Created the getNote method that will be reused in addCollaborator and
getCollaborators since these methods need a Note object.

Collaborator validation should not be responsibility of
addCollaborators.

Since loading a note does a database query, we change all the methods
in SimperiumCollaboratorsRepository to suspend methods. To be able to
test properly the repository, we need to inject the dispatcher, so we
updated the dispatcher in all the test and created a provider for Hilt.

Tests on model does not require emulator. They can run fast and are
better suited to run as unit tests instead of connected tests.

Make explicit that TagValidationResult is part and just used in
ValidateTagUseCase.

The SimperiumCollaboratorsRepository now has a dependency for
Bucket<Note>, thus, all tests that use the instance directly had to be
updated.

Given that notes are synchronized across different devices, there may
be the case in which a user will try to get the collaborators of a note
that was deleted or is in the trash. For those cases, we cannot add
collaborators.

Collaborator validation should not be responsibility of
addCollaborators.

Since loading a note does a database query, we change all the methods
in SimperiumCollaboratorsRepository to suspend methods. To be able to
test properly the repository, we need to inject the dispatcher, so we
updated the dispatcher in all the test and created a provider for Hilt.

Add tests for loadCollaborators and removeCollaborator. Add collaborator
will be handled in another ViewModel.

Moved NoteInTrash and NoteDeleted as UiState since the UI must make a
decision when the note is in trash or deleted. The ViewModel will not
provide collaborators for notes in these states.

This field is not needed now but might be added later when UI is
implemented.

In case there are not collaborators added, a special state is returned
since the UI will perform certain actions for this case.

Show an alert dialog before removing a collaborator. In case the user
taps on Remove, then call the ViewModel to remove the collaborator.

Initial version without implementation of AddCollaboratorViewModel.

The noteId is sent to the fragment so it can add the collaborator to the
correct Note

Listen to changes on the note that might mean the collaborators were
updated. This works for when a new collaborator is added locally or
from another client.

The list of collaborators is obtained from a single note. Loading the
note is not a heavy task, thus, the progress bar in this case is
overkill.

If the user is editing the collaborators of a note that is trashed or
deleted, the user is returned to the list of activities since
collaborators cannot be added to trashed or deleted notes.

Improve positioning of views in layout to handle list of collaborators.
The list is scrollable to handle long list of collaborators.

When the configuration changes, Android tries to recreate the dialog
fragment. Since the previous AddCollaboratorFragment's constructor
had one parameter, the instance could be recreated. Now we pass the
note ID through Bundle objects as arguments.

Reformat manifest with the previous format and add CollaboratorsActivity
with android:configChanges="orientation|keyboardHidden|screenSize"

Now the fragment stays when the configuration changes, thus, we do not
have to handle instance creation.

The action of removing a collaborator will be handled by the flow when
the collaborators changed.

Use the IO dispatcher in the getNote method and let all other three
methods free of using any dispatcher.

Keep consistency on how the two methods are layered afterwards.