Filter out appservices from mau count

[Half-Shot]

This is an attempt to fix #8403, however i'm totally failing to find the correct join magic to make this work.

[anoadragon453]

I'm a little worried that in the past we seem to have tracked application service users specifically in monthly user stats (e.g. #7030).

Also this looks like it might break some reporting graphs:

synapse/synapse/app/homeserver.py

Lines 639 to 648 in 837293c

	if hs.config.limit_usage_by_mau or hs.config.mau_stats_only:
	current_mau_count = await store.get_monthly_active_count()
	current_mau_count_by_service = (
	await store.get_monthly_active_count_by_service()
	)
	reserved_users = await store.get_registered_reserved_users()
	current_mau_gauge.set(float(current_mau_count))
	for app_service, count in current_mau_count_by_service.items():
	current_mau_by_service_gauge.labels(app_service).set(float(count))

I'd like a comment from @neilisfragile here before we go any further.

Alternatively, we may be able to fix this at a higher abstraction level.

[Half-Shot]

I'm a little worried that in the past we seem to have tracked application service users specifically in monthly user stats (e.g. #7030).

This doesn't break that. The metric synapse_admin_mau_current_mau_by_service will continue to report this, but what this change will do is ensure that synapse won't block login/sync/actions due to appservices eating into MAU limits, which sounds desirable to me.

If folks still want to determine the total number of users, they should use sum(synapse_admin_mau_current_mau_by_service)

(As an aside, this metric has been broken for a while anyway -- appservice users aren't tracked at all until they /sync, which means this reporting system was broken for the vast majority of services anyway from day 1)

[anoadragon453]

Thanks for the explanation. I'd still like to get a once-over from Neil, but it looks good from my perspective code-wise.

[neilisfragile]

LGTM.

The only reason for the app service split out was an ask from EMS, so if it is not useful it can happily be ripped out. No need to delay this PR for that though.

[anoadragon453]

Sounds good, thanks all!