Basic logic for tracking projects/groups visits in the backend

What does this MR do and why?

Basic logic for tracking projects/groups visits in the backend

This adds the tables, worker and minimal logic to start tracking projects and groups pages visits in the backend.

Screenshots or screen recordings

No visual change.

How to set up and validate locally

1. Enable the :server_side_frecent_namespaces feature flag.

   Feature.enable(:server_side_frecent_namespaces)

2. Run the migrations:

   bin/rails db:migrate RAILS_ENV=development

3. Connect to your development DB:

   gdk psql -d gitlabhq_development

4. Verify the visits tables' state:
   1. SELECT * FROM projects_visits;
   2. SELECT * FROM groups_visits;
5. Navigate to either a group or a project in the GDK.
   • An Ajax POST request should be sent to the /-/track_visits endpoint.
   • Running the relevant SQL query again from the previous step, you should now see one more entry.
   • Note: The new entry might take a while to show up as is being saved asynchronously by a low-urgency worker.
6. Visiting a project or a group within 15 minutes of the last visit should no trigger the Ajax request again.

SQL queries

The ProjectVisit and GroupVisit models can be queried via the visited_around? method which accepts an entity ID, a user ID and a datetime, and searches for any visits that occurred somewhere between 15 minutes before and after the provided time. Here's what the raw SQL could look like:

SELECT
    1 AS one
FROM
    "projects_visits"
WHERE
    "projects_visits"."entity_id" = 21
    AND "projects_visits"."user_id" = 1
    AND "projects_visits"."visited_at" BETWEEN '2023-09-11 06:30:22.656342' AND '2023-09-11 07:00:22.656342'
LIMIT 1

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #431043 (closed)