SPIKE: MODKBEKBJ-504 User patron groups should be in sync with users app

MODKBEKBJ-504 - Getting issue details... STATUS

The main goal of this spike is to investigate how can we display actual user-related information in assigned-users list for kb-credentials.

Current problem:

User data is saved in mod-kb-ebsco when user is assigned and then never updated so if data is modified in mod-users then data in mod-kb-ebsco becomes not relevant.

Current "assigned users" interactions

Possible solutions:

	Pub-sub between mod-users and mod-kb-ebsco-java	Bulk api for users in mod-users
	Pub-sub between mod-users and mod-kb-ebsco-java	Query data every time it's needed	implement scheduler to periodically update assigned users data
Advantages	Most preferable way for data consistency achievement. Good performance for UX.	No need to store duplicate data and worry for data consistency.	Ensures data consistency. Good performance for UX.
Disadvantages	Will cause a lot of "dummy" network traffic and unnecessary component load because kb-ebsco needs info only about certain users not all.	Worst user-experience cause we need query data from multiple sources to display assigned users info so this will cause delays for data displaying.	Wasted processor time in most cases and delays in data consistency depending on scheduler rate. Also unnecessary api calls in cases data is already consistent. Potentially can cause big performance issues as database grows.
Developers effort to implement	Almost no changes to current code. Add producer on `mod-users` on data changes and consumer for `mod-kb-ebsco` to updated data based on notifications.	Rework database structure in `mod-kb-ebsco` (remove user-related info) to store only kb-id to user-id relations and update user assignment flow. Implement bulk api in `mod-users`. Add bulk api call to `mod-kb-ebsco` user assignment flow.	Implement bulk api in `mod-users`. Add bulk api call to `mod-kb-ebsco` scheduler or implement api and let `okapi` run it periodically to update data.

Conclusion:

It was decided to remove user data from mod-kb-ebsco and query user-related info every time it is needed. Bulk api is not needed because users can be queried using cql.

To be implemented:

Note	Work to be done	Module	Story
Do anytime	Remove call to "/groups" api (i suppose it's even not used now) Note: actually this is not a part of this spike, just wonder whether this api call is dummy. If so - it should be removed, but spike can be completed without this.	front-end/ui-eholdings	UIEH-1236 - Getting issue details... STATUS
Do first	Rework "GET /kb-credentials/{kb-credentials-id}/users" api: get assigned users from db (only user ids by kb_credentials_id) query users info from `mod-users` for assigned users using "/users" api and cql (Check the max possible amount of users we can query this way and implement batches so if for example we have 200 assigned users in db and the limit is 50 then we should execute 4 queries with 50 users each and compose results then) query groups info using "/groups" api of `mod-users` aggregate received info and pass as response	back-end/mod-kb-ebsco	MODKBEKBJ-621 - Getting issue details... STATUS
Do together	Update "POST /eholdings/kb-credentials/{kb-credentials-id}/users": remove "firstName", "lastName", "patronGroup", "userName" from api update repository interaction (save only kb_id to user_id relation)	back-end/mod-kb-ebsco	MODKBEKBJ-622 - Getting issue details... STATUS
Do together	Update call to "POST /eholdings/kb-credentials/{kb-credentials-id}/users": remove "firstName", "lastName", "patronGroup", "userName" from request body also do not depend on this fields in response	front-end/ui-eholdings	UIEH-1237 - Getting issue details... STATUS
Do last	Schema updates: remove `kb_users` table from db remove `assigned_users_view` update `assigned_users` constraint(user id is a foreign key now, but users table will be removed) update `access_types` (remove view, constraints) Code updates: remove unused repository update repository for new schema remove other unused code related to user data rework 'access-types' api to query user-related data from '/users' api of mod-users instead of database	back-end/mod-kb-ebsco	MODKBEKBJ-623 - Getting issue details... STATUS