Add automated/transparent MultiLang workflow support with multiple fallback languages

(In [24971]) Add automated/transparent MultiLang? workflow support with multiple fallback languages, fixes #1626

(In [24972]) Parameter domains use dots, use here too, refs #1626

Actually automated lang0 syncing (using lang0 as a fallback where best match is placed) would have also been possible if deletions would have been per language only and last langX delete would have always deleted full objects (possible with action_delete and action_deleted callbacks).

I tried to create the workflow in a way deletes affect full objects and that was impossible with that syncing solution because MidCOM can't see the object in langX if object doesn't have a langX translation. Well, not fully impossible as it would have worked from languages where translation exists. (It would have been a bit unclear but it would have worked in practice because translation would exist in practice in those cases usually.)

If someone actually needs that kind of workflow, we can add new method(s) to the class for that purpose. You know, we now have "auto" workflow but we could also have e.g. "lang0" workflow in the future.

Now that I think about this, it seems there are multiple different kind of workflows which are possible. There are at least two different kind of fallback handling possibilities (in addition to the built-in one). Then there are at least two different kind of delete handling possibilities (delete only translation vs. delete full object).

Some of the workflows would require a bit more complex code to be written. For example when deleting a full object, it should always be done in a way its children are all also deleted as full objects (otherwise the database is left in a state where there are active objects without parents). Normally midcom.admin.folder (and Asgard) handle those recursive deletions but in this case as the delete workflow would be different/special, it would have to be handled in the workflow itself I guess. (The "lang0" workflow would need this kind of solution in both delete handling cases because that workflow would not have all translations in the current language in all situations.)

Clearly implementing all possibilities would take a bit of time. I guess it makes no sense to do it without actual real life need. If there is a need it's quite fast to implement a new worklow to the class then because it's just one workflow then in question.

It seems the worklow I ended up implementing is indeed the simplest one. We need no special delete handling code because the language always has all the objects visible and all objects are deleted recursively in normal MidCOM operations.

(In [24976]) Add multilang auto workflow support to fi.protie.navigation's untranslated CSS class handling, refs #1626

(In [24977]) Use the service's own get_lang() because we want to get the empty string instead of null in lang0 case (lang0 usage is discouraged but this way it should work if used), refs #1626

I think I need to reconsider the implementation of deletes because it seems it adds difficulty a lot when lang0 is not used. You know, page elements etc. don't function like you'd assume because they are normally in lang0 and setting default_lang masks them. (Actually I still got style working but root topic was strangely found but incorrect...) Of course we could put everything into correct lang but I don't like the idea of duplicating everything because of this. It might make more sense to handle lang0 a bit similarly as SG0 is handled regarding the sitegroups functionality.

Reopening to state it clearly that this feature/ticket is not yet finished. Implementation (and even behavior) might still change a bit. I need to make some tests and decide what is the best implementation.

(In [24978]) Don't change default_lang but instead change lang to default_lang when deleting (same end effect but allows lang0 to be used like SG0 is used with sitegroups), refs #1626

(In [24980]) Add generic get_default_lang() and use it, refs #1626

(In [24982]) Rename reset_lang() to set_lang_back() because we actually want to return to latest lang (which needs to be set by calling set_lang_back() first) instead of initial lang (although in practice they are of course the same). Move set_lang_back() lower so that we have the event handlers ordered logically in the class. As set_lang_back() is now called always before it's used, remove reset_lang() call from the auto workflow method as it's no longer needed. Refs #1626

Ok, this implementation seems to work and is still simple (and simpler to use than the original one). Feature is complete.

I realized that if delete fails, lang is left to lang0. I thought about it and it seems it's still better this way because this solution solved a real life problem and that problem is more like a theoretic one.

It's theoretic because this version of Midgard doesn't check for privileges internally except for sitegroup boundary crossing. Basically delete can fail only if the object doesn't really exist or is somehow corrupted. MidCOM checks all those cases before it tries to delete objects so in practice we shouldn't ever get to the point where delete fails internally.

I also thought about whether it is better to change lang to default_lang or the other way and it seems the current implementation is better because lang0 is used for the actual site and langX for content. It is a much bigger problem if the site's language changes than if content language changes. (Because if site language changes, MidCOM's finish stage would not be executed.)

Although this is not perfect it seems this is the best solution in practice. This ticket itself is a solution which is the best in practice but not perfect. :)

It seems using default_lang like SG0 is used with sitegroups (master one which can control everything) is not something which can be relied on.

I guess it should be done the other way then: default_lang should be changed to lang before delete() and back afterwards. (This means lang needs to be set back also because of the way set_default_lang() works.)

Even though I wrote above that doing it that way might be a bit problematic it shouldn't be an issue in real life.

Reopening because feature is not complete yet because of this. It works with current Midgard version but should be changed so that it works with future versions as well.

(In [24995]) Change delete implementation, fixes #1626