Anonymous view descriptor fetchPlan naming can cause UB

[syncro]

Environment

Jmix version: 2.x

Bug Description

Currently fetchPlans that are declared in view xml-descriptors are taking the same name with the following pattern ${fqdn}/.
By this naming strategy different kinds of result sets can have the same fetchplan identification that can cause problems in many cases, e.g. unwanted reloading from database with unsaved changes discard, lazy loading or "unfetched" exceptions.

It's proposed to add DataContainer id and View id to fetchplan name when it has uniquie properties configuration.

In addition saveAndClose logic of StandardDetailView can be more tolerant to fetchplan differences and configurable.

Steps To Reproduce

1. Take attached sample project or create new project with one to many fields and reference types. Generate and code transactional UI for them, that saves data only with parent entity. Child entity must have own detail view xml-declared fetch plan with at least one field that is not loaded by default base fetchPlan, e.g. type that referencing to other entity.
2. Go to UI create new agregating entity (Product set) item but not save
3. Add Product to it but do not save Procuts set
4. Open previously added product again, do some changes and press OK

Screencast.anon.fetchPlans.naming.mp4

Current Behavior

Previously made changes are discarded because of forced by grid and detail fetchplans structure divergence that cased forced data reload

Expected Behavior

Changes are commited and saved to database

Sample Project

testjmix280.zip

[syncro]

bulkEditor is reported as potentially having similar problems near BulkEditView.setupItemsToEdit() method