fix(lms): do not add observers or mentors as students

[stephenliang]

Warning!!

The AP CSP Create Performance Task is in progress. The most critical dates are from April 3 - April 30, 2024. Please consider any risk introduced by this PR that could affect our students taking AP CSP. Code.org students taking AP CSP primarily use App Lab for their Create Task, however a small percent use Game Lab. Carefully consider whether your change has any risk of alterering, changing, or breaking anything in these two labs. Even small changes, such as a different button color, are considered significant during this time period. Reach out to the Student Learning team or Curriculum team for more details.

Previously, we added all non-teachers to the student roster. However, this includes observers or mentors which are typically parents observing their child's progress. Observers should not be added as students in the roster.

Links

Testing story

Added observers to the sync mock object and ensured followers do not increment. Prior to the fix, the unit test fails with:

Minitest::Assertion: Expected: 4
  Actual: 3
test/lib/services/lti_test.rb:458:in `block in <class:LtiTest>'
test/testing/setup_all_and_teardown_all.rb:36:in `run'

Minitest::Assertion: Expected: 2
  Actual: 3
test/lib/services/lti_test.rb:495:in `block in <class:LtiTest>'
test/testing/setup_all_and_teardown_all.rb:36:in `run'

Minitest::Assertion: Expected: 3
  Actual: 4
test/lib/services/lti_test.rb:521:in `block in <class:LtiTest>'
test/testing/setup_all_and_teardown_all.rb:36:in `run'

Minitest::Assertion: Expected: 6
  Actual: 5
test/lib/services/lti_test.rb:384:in `block (2 levels) in <class:LtiTest>'
test/lib/services/lti_test.rb:382:in `each'
test/lib/services/lti_test.rb:382:in `block in <class:LtiTest>'
test/testing/setup_all_and_teardown_all.rb:36:in `run'

Deployment strategy

Follow-up work

Privacy

Security

Caching

PR Checklist:

• Tests provide adequate coverage
• Privacy and Security impacts have been assessed
• Code is well-commented
• New features are translatable or updates will not break translations
• Relevant documentation has been added or updated
• User impact is well-understood and desirable
• Pull Request is labeled appropriately
• Follow-up work items (including potential tech debt) are tracked and linked

[mgc1194]

I like the small incremental change of this PR. The new logic makes sense. I also appreciate adding the new role to tests as well.