Currently table_sql and its derivatives are entirely configured via their constructor and one-off endpoints (e.g. /user/index.php).

I am proposing the following changes:

1. Update lib/components.json to define the existing "table" subsystem in "lib\/table"
2. create a new interface \core_table\dynamic (or similar) in lib/table/classes/dynamic.php. Can be initially empty while we work the full details out
3. have our existing user class implement the new interface (\core_user\participants_table)
4. move all logic from the current constructor of the participants table to the new argument processing system, and update the calls to it in user/index.php
5. create a new web service to fetch a table_sql view;

Interface and implementation in participants table

1. Will need functions including:
   1. get_unique_id_from_argument(string $argument): string; (discussed below);
   2. get_base_url(): \moodle_url;
   3. process_arguments: void

Webservice

1. Will have a WS name like 'core_table_dynamic' and be located in \core\table\external\dynamic (lib/table/classes/external/dynamic.php)
2. Should take arguments:
   1. handler - the auto-loadable class name of a class extending table_sql and implementing \core_table\dynamic
   2. uniqueid - the unique id of the table:
      1. This is typically done in the class extending table_sql. e.g in \core_user\participants_table we call parent::__construct('user-index-participants-' . $courseid) - so the unique id is user-index-participants-[\d+]
      2. We may wish to create a static function on the interface + implementation like get_unique_id_from_argument(string $argument): string;
      3. We can then create an implementation in the participants table like:

         public static function get_unique_id_from_argument(string $argument): string {

         return "user-index-participants-{$argument}";

         }

         And in our WS we can use it like:

         if (!class_exists($handler) || !is_subclass_of($handler, \core_table\dynamic::class)) {

         throw new \Exception('Not supported');

         }

         $instance = new $handler($handler::get_unique_id_from_argument($uniqueid));

   3. filters - the list of filters to the table. This is essentially the extra arguments currently provided to the constructor.
      1. We probably want to make this a list of key/value pairs or a JSON string that we can decode and pass to the instantiated class
3. We will return:
   1. list of data attributes which correlates to the input received
   2. Raw HTML raw
      1. In future we will update the table_sql and flexible_table classes to make use of a set of templates, and we can then return the template name, and a data structure