Rework database modules and class names

The main goal for this work is consistency in naming surrounding the
database models.

Most of the code refers to "auth tokens" in various contexts. As such,
"active token(s)" names are renamed to "auth token(s)".

Related to that, we update other database modules so that they follow
the same pattern of singluar module name and plural table names.  The
plural table names are more natural when constructing SQL queries.  We
also change the database module model names to follow their table names.

One notable change is that the `database.model.server_configs` module
has been renamed to `database.model.server_settings`, with the ORM class
name renamed from `ServerConfig` to `ServerSetting`.

We are making both changes in this commit so that we can provide one
database migration for the changes.

docs/API/V1/server_config.md → docs/API/V1/server_settings.md

@@ -1,9 +1,9 @@
-# `GET /api/v1/server/configuration[/][{key}]`
+# `GET /api/v1/server/settings[/][{key}]`
 
 This API returns an `application/json` document describing the Pbench Server
-configuration settings. When the `{key}` parameter is specified, the API will
-return the specific named server configuration setting. When `{key}` is omitted,
-all server configuration settings will be returned.
+settings. When the `{key}` parameter is specified, the API will return the
+specific named server setting. When `{key}` is omitted, all server settings will
+be returned.
 
 ## Query parameters
 
@@ -13,35 +13,34 @@ None.
 
 `authorization: bearer` token [_optional_] \
 *Bearer* schema authorization may be specified, but is not required to `GET`
-server configuration settings.
+server settings.
 
 ## Response headers
 
 `content-type: application/json` \
-The return is a serialized JSON object with the requested server configuration
-settings.
+The return is a serialized JSON object with the requested server settings.
 
 ## Response status
 
 `400`   **BAD REQUEST** \
-The specified `{key}` value (see [settings](#server-configuration-settings))
+The specified `{key}` value (see [settings](#server-settings))
 is unknown.
 
 ## Response body
 
 The `application/json` response body is a JSON document containing the requested
-server configuration setting key and value or, if no `{key}` was specified, all
-supported server configuration settings.
+server setting key and value or, if no `{key}` was specified, all supported
+server settings.
 
 ### Examples
 
 ```
-GET /api/v1/server/configuration/dataset-lifetime
+GET /api/v1/server/settings/dataset-lifetime
 {
     "dataset-lifetime": "4"
 }
 
-GET /api/v1/server/configuration/
+GET /api/v1/server/settings/
 {
     "dataset-lifetime": "4",
     "server-banner": {
@@ -55,29 +54,28 @@ GET /api/v1/server/configuration/
 }
 ```
 
-# `PUT /api/v1/server/configuration[/][{key}]`
+# `PUT /api/v1/server/settings[/][{key}]`
 
-This API allows a user holding the `ADMIN` role to modify server configuration
-settings. When the `{key}` parameter is specified, the API will modify a single
-named configuration setting. When `{key}` is omitted, the `application/json`
-request body can be used to modify multiple configuration settings at once.
+This API allows a user holding the `ADMIN` role to modify server settings. When
+the `{key}` parameter is specified, the API will modify a single named setting.
+When `{key}` is omitted, the `application/json` request body can be used to
+modify multiple server settings at once.
 
 ## Query parameters
 
 `value`    string \
-When a single configuration setting is specified with `{key}` in the URI, you
-can specify a string value for the parameter using this query parameter without
-an `application/json` request body. For example,
-`PUT /api/v1/server/configuration/key?value=1`.
+When a single server setting is specified with `{key}` in the URI, you can
+specify a string value for the parameter using this query parameter without an
+`application/json` request body. For example, `PUT /api/v1/server/settings/key?value=1`.
 
-You cannot specify complex JSON configuration settings this way. Instead, use
-the `value` field in the `application/json` request body.
+You cannot specify complex JSON server settings this way. Instead, use the
+`value` field in the `application/json` request body.
 
 ## Request body
 
-When specifying a complex JSON value for a server configuration setting, or when
-specifying multiple configuration settings, the data to be set is specified in
-an `application/json` request body.
+When specifying a complex JSON value for a server setting, or when specifying
+multiple server settings, the data to be set is specified in an
+`application/json` request body.
 
 You can specify a single `{key}` in the URI and then specify the value
 using a `value` field in the `application/json` request body instead of using
@@ -86,19 +84,18 @@ string, although it's more useful when you need to specify a JSON object value.
 For example,
 
 ```
-PUT /api/v1/server/configuration/server-state
+PUT /api/v1/server/settings/server-state
 {
     "value": {"status": "enabled"}
 }
 ```
 
-If you omit the `{key}` value from the URI, specify all configuration settings
-you wish to change in the `application/json` request body. You can specify a
-single server configuration setting, or any group of server configuration
-settings at once. For example,
+If you omit the `{key}` value from the URI, specify all server settings you wish
+to change in the `application/json` request body. You can specify a single
+server setting, or any group of server settings at once. For example,
 
 ```
-PUT /api/v1/server/configuration/
+PUT /api/v1/server/settings/
 {
     "server-state": {"status": "disabled", "message": "down for maintenance"},
     "server-banner": {"message": "Days of 100% uptime: 0"}
@@ -108,14 +105,13 @@ PUT /api/v1/server/configuration/
 ## Request headers
 
 `authorization: bearer` token \
-*Bearer* schema authorization is required to change any server configuration
-settings. The authenticated user must have `ADMIN` role.
+*Bearer* schema authorization is required to change any server settings. The
+authenticated user must have `ADMIN` role.
 
 ## Response headers
 
 `content-type: application/json` \
-The response body is a serialized JSON object with the selected server
-configuration settings.
+The response body is a serialized JSON object with the selected server settings.
 
 ## Response status
 
@@ -129,13 +125,12 @@ role.
 ## Response body
 
 The `application/json` response body for `PUT` is exactly the same as for
-[`GET`](#response-body) when the same server configuration settings are
-requested, showing only the server configuration settings that were changed
-in the `PUT`.
+[`GET`](#response-body) when the same server settings are requested, showing
+only the server settings that were changed in the `PUT`.
 
 _This request:_
 ```
-PUT /api/v1/server/configuration/dataset-lifetime?value=4
+PUT /api/v1/server/settings/dataset-lifetime?value=4
 ```
 
 _returns this response:_
@@ -148,7 +143,7 @@ _returns this response:_
 
 _And this request:_
 ```
-PUT /api/v1/server/configuration
+PUT /api/v1/server/settings
 {
     "dataset-lifetime": "4 days",
     "server-state": {"status": "enabled"}
@@ -163,18 +158,17 @@ _returns this response:_
 }
 ```
 
-## Server configuration settings
+## Server settings
 
 ### dataset-lifetime
 
-The value for the `dataset-lifetime` server configuration setting is the *maximum*
-number of days a dataset can be retained on the server. When each dataset is
-uploaded to the server, a "deletion date" represented by the dataset
-[metadata](../metadata.md) key `server.deletion` is calculated based on this
-value and user preferences (which may specify a shorter lifetime, but not a
-longer lifetime). When a dataset has remained on the server past the
-`server.deletion` date, it may be removed automatically by the server to
-conserve space.
+The value for the `dataset-lifetime` server setting is the *maximum* number of
+days a dataset can be retained on the server. When each dataset is uploaded to
+the server, a "deletion date" represented by the dataset [metadata](../metadata.md)
+key `server.deletion` is calculated based on this value and user preferences
+(which may specify a shorter lifetime, but not a longer lifetime). When a
+dataset has remained on the server past the `server.deletion` date, it may be
+removed automatically by the server to conserve space.
 
 The number of days is specified as an string representing an integer, optionally
 followed by a space and `day` or `days`. For example, "4" or "4 days" or "4 day"
@@ -188,14 +182,14 @@ are equivalent.
 
 ### server-banner
 
-This server configuration setting allows a server administrator to set an
-informational message that can be retrieved and displayed by any client, for
-example as a banner on a UI. The value is a JSON object, containing at least
-a `message` field.
+This server setting allows a server administrator to set an informational
+message that can be retrieved and displayed by any client, for example as a
+banner on a UI. The value is a JSON object, containing at least a `message`
+field.
 
 Any additional JSON data may be provided. The server will store the entire
 JSON object and return it when a client requests it with
-`GET /api/v1/server/configuration/server-banner`. The server will not interpret
+`GET /api/v1/server/settings/server-banner`. The server will not interpret
 any information in this JSON object.
 
 For example, the following are examples of valid banners:
@@ -228,25 +222,26 @@ For example, the following are examples of valid banners:
 
 ### server-state
 
-This server configuration setting allows a server administrator to control
-the operating state of the server remotely. As for
-[`server-banner`](#server-banner), the value is a JSON object, and any JSON
-fields passed in to the server will be returned to a client. The
-following fields have special meaning:
+This server setting allows a server administrator to control the operating state
+of the server remotely. As for [`server-banner`](#server-banner), the value is a
+JSON object, and any JSON fields passed in to the server will be returned to a
+client. The following fields have special meaning:
 
 **`status`** \
 The operating status of the server.
 
 * `enabled`: Normal operation.
 * `disabled`: Most server API endpoints will fail with the **503** (service
 unavailable) HTTP status. However a few endpoints are always allowed:
-  * [endpoints](./endpoints.md) for server configuration information;
+  * [endpoints](./endpoints.md) for server settings information;
   * [login](./login.md) because only an authenticated user with `ADMIN` role
-    can modify server configuration settings;
+    can modify server settings;
   * [logout](./logout.md) for consistency;
-  * [server_configuration](./server_config.md) to allow re-enabling the server
+  * [server_settings](./server_settings.md) to allow re-enabling the server
     or modifying the banner.
-* `readonly`: The server will respond to `GET` requests for information, but will return **503** (service unavailable) for any attempt to modify server state. (With the same exceptions as listed above for `disabled`.)
+* `readonly`: The server will respond to `GET` requests for information, but
+will return **503** (service unavailable) for any attempt to modify server
+state. (With the same exceptions as listed above for `disabled`.)
 
 **`message`** \
 A message to explain downtime. This is required when the `status` is `disabled`
@@ -261,8 +256,7 @@ will display this as an explanation for the failure. The client will also have
 access to any additional information provided in the `server-state` JSON object.
 
 Note that you can set a `message` when the `status` is `enabled` but it won't
-be reported to a client unless a client asks for the `server-state`
-configuration setting. The `server-state` message is intended to explain server
-downtime when an API call fails. The `server-banner` configuration setting
-is generally more appropriate to provide client information under normal
-operating conditions.
+be reported to a client unless a client asks for the `server-state` setting. The
+`server-state` message is intended to explain server downtime when an API call
+fails. The `server-banner` setting is generally more appropriate to provide
+client information under normal operating conditions.

lib/pbench/server/api/__init__.py

@@ -36,7 +36,7 @@
 from pbench.server.api.resources.query_apis.datasets_publish import DatasetsPublish
 from pbench.server.api.resources.query_apis.datasets_search import DatasetsSearch
 from pbench.server.api.resources.server_audit import ServerAudit
-from pbench.server.api.resources.server_configuration import ServerConfiguration
+from pbench.server.api.resources.server_settings import ServerSettings
 from pbench.server.api.resources.upload_api import Upload
 from pbench.server.api.resources.users_api import Login, Logout, RegisterUser, UserAPI
 from pbench.server.auth.auth import Auth
@@ -163,11 +163,11 @@ def register_endpoints(api, app, config):
         resource_class_args=(config,),
     )
     api.add_resource(
-        ServerConfiguration,
-        f"{base_uri}/server/configuration",
-        f"{base_uri}/server/configuration/",
-        f"{base_uri}/server/configuration/<string:key>",
-        endpoint="server_configuration",
+        ServerSettings,
+        f"{base_uri}/server/settings",
+        f"{base_uri}/server/settings/",
+        f"{base_uri}/server/settings/<string:key>",
+        endpoint="server_settings",
         resource_class_args=(config,),
     )
     api.add_resource(

lib/pbench/server/api/resources/__init__.py

@@ -27,7 +27,7 @@
     MetadataBadKey,
     MetadataError,
 )
-from pbench.server.database.models.server_config import ServerConfig
+from pbench.server.database.models.server_settings import ServerSetting
 from pbench.server.database.models.users import User
 
 
@@ -1556,7 +1556,7 @@ def _dispatch(
         schema = self.schemas[method]
         if not self.always_enabled:
             readonly = schema.operation == OperationCode.READ
-            disabled = ServerConfig.get_disabled(readonly=readonly)
+            disabled = ServerSetting.get_disabled(readonly=readonly)
             if disabled:
                 abort(HTTPStatus.SERVICE_UNAVAILABLE, **disabled)
 

lib/pbench/server/api/resources/query_apis/__init__.py

@@ -32,7 +32,7 @@
 from pbench.server.auth.auth import Auth
 from pbench.server.database.models.audit import AuditReason, AuditStatus
 from pbench.server.database.models.datasets import Dataset, Metadata, States
-from pbench.server.database.models.template import Template
+from pbench.server.database.models.templates import Template
 from pbench.server.database.models.users import User
 
 

lib/pbench/server/api/resources/query_apis/datasets/__init__.py

@@ -14,7 +14,7 @@
 )
 from pbench.server.api.resources.query_apis import ElasticBase
 from pbench.server.database.models.datasets import Dataset, Metadata, MetadataError
-from pbench.server.database.models.template import Template
+from pbench.server.database.models.templates import Template
 
 
 class MissingDatasetNameParameter(SchemaError):

lib/pbench/server/api/resources/query_apis/datasets/datasets_mappings.py

@@ -15,7 +15,7 @@
     Schema,
 )
 from pbench.server.api.resources.query_apis.datasets import IndexMapBase
-from pbench.server.database.models.template import TemplateNotFound
+from pbench.server.database.models.templates import TemplateNotFound
 
 
 class DatasetsMappings(ApiBase):

lib/pbench/server/api/resources/query_apis/datasets/namespace_and_rows.py

@@ -16,7 +16,7 @@
 from pbench.server.api.resources.query_apis import ApiContext, PostprocessError
 from pbench.server.api.resources.query_apis.datasets import IndexMapBase
 from pbench.server.database.models.datasets import Dataset
-from pbench.server.database.models.template import TemplateNotFound
+from pbench.server.database.models.templates import TemplateNotFound
 
 
 class SampleNamespace(IndexMapBase):