Exclude bots from licensed user count

What does this MR do?

As outlined in #223695 (closed), we identified that project bot users were being included as users taking a seat in licensed SM instances. After spending a bit of time investigating, I found that these were being included because

Context

Current active users for EE are calculated in the License model here. The main thing to note is that it uses the :active scope defined here in the User model. This scope is comprised of users with "active" and the :non_internal scope (defined here). This :non_internal scope is the key piece to sort for this MR. Previous to this MR, it appears that all bots were considered internal, and therefore would be excluded from the active users count calculated (and not billed).

However, when project bots were introduced in this MR, they were specifically included in the list of non internal user types and therefore were considered active and took up seats. After confirming with @asubramanian1, we determined that project bots should indeed be considered active (and non internal) but shouldn't be included in billing. This meant a change to the existing logic to determine who takes up licensed seats. That's where this MR comes in.

Included in the MR

• Introduce a new User scope called without_bots.
• Use this scope to exclude bots from the current active users count logic in License model.
• Adds the method current_active_users to License for easy reuse throughout the app when determining users who take up seats in SM instances.
• Update references across the app to use current_active_users instead of User.active.count.

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team

Relates to #223695 (closed)