Introduce read-only users in jambonz webapp

[rammohan-y]

Currently all users created can perform CRUD operations based on the scope, it will be useful to introduce read-only users who can view the configurations but cannot create/modify/delete.

[rammohan-y]

Design:

a. Database changes:

1. Add is_read_only boolean column to the users table with a default value of false in upgrade-jambonz-db.js with 9004 key and also in jambones-sql.sql file

b. Middleware changes

1. Create checkReadOnlyUser middleware function that:
2. Skips check for GET requests (read operations allowed)
3. For non-GET requests, checks if user has is_read_only flag as true, if true then only proceed further in the request
4. Throws 403 Forbidden error if read-only user attempts write operations

c. Login Integration

1. Modify login response to include is_read_only status in JWT payload
2. This allows the middleware to know user's read-only status, frontend will also have access to this status for future purposes

d. User Management

1. Add the ability to update user's read-only status via API

e. Webapp change

1. Introduce a checkbox in user management screen for selecting the user as "Read-Only"

f. Summary

1. Read operations (GET) are always allowed
2. Write operations (POST/PUT/DELETE) are blocked for read-only users
3. The read-only status is enforced at the middleware level, ensuring consistent application across all API endpoints
4. The read-only status is included in the JWT token, making it available throughout the application
5. Only authorized users can modify the read-only status of other users
6. This feature allows for creating users with restricted access, useful for scenarios where users should only be able to view but not modify data.

### Note: The upgrade-jambonz-db needs to be executed for existing installations without which the webapp application and api-server will fail

@davehorton @xquanluu

[davehorton]

created linked issue: jambonz/jambonz-webapp#477

As far as implementation, I don't think we need to add a new column actually. We already have a "permissions" table that is linked to each user, with these possible values

MySQL [jambones]> select * from permissions;
+--------------------------------------+--------------------+------------------------------------+
| permission_sid                       | name               | description                        |
+--------------------------------------+--------------------+------------------------------------+
| ffbc342a-546a-11ed-bdc3-0242ac120002 | VIEW_ONLY          | Can view data but not make changes |
| ffbc3a10-546a-11ed-bdc3-0242ac120002 | PROVISION_SERVICES | Can provision services             |
| ffbc3c5e-546a-11ed-bdc3-0242ac120002 | PROVISION_USERS    | Can provision users                |
+--------------------------------------+--------------------+------------------------------------+
3 rows in set (0.003 sec)

I believe when a user logs in that information is returned in the POST /login request. Let's use the VIEW_ONLY permission to indicate this user should not be allowed to perform any updates from the webapp.

I don't know that the current code does much with that data, but it was put there originally in anticipation of this readonly user feature actually.