feat(actions): standardize contexts

[skjnldsv]

Following discussion on #1113

This would be a breaking change unless we add a conversion layer to support the old legacy way.
BUT, the cleanest way, imho, is to quickly update server and communicate to devs asap

// Before
action.exec(node, view, '/path/to/node')

// After
action.exec({
	nodes: [node],
	view: View,
	context: Folder
})

[codecov]

Bundle Report

Bundle size has no change ✅

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.62%. Comparing base (f1d1a84) to head (d994eb4).
Report is 33 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1124   +/-   ##
=======================================
  Coverage   91.62%   91.62%           
=======================================
  Files          23       23           
  Lines         633      633           
  Branches      166      166           
=======================================
  Hits          580      580           
  Misses         46       46           
  Partials        7        7           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[susnux]

BUT, the cleanest way, imho, is to quickly update server and communicate to devs asap

I would try to make the library to work with all supported Nextcloud versions.
This makes it hard to impossible to maintain multi-version apps (e.g. things like groupware).
So I think we should make sure this works with 30, 29, and 28.

What I mean is we can do it like in this PR, which would be breaking and a v4 of the library.
But it would then only be a breaking change of this library we should not break the server API which we should support as of our deprecation rules (at least 3 version, I do not want to go the 9 versions 3 years way 🙈 )

So how to do it while not breaking server API?
Change the registerFileAction function in this PR to use a new _nc_fileactions_v2 to store them.
And in getFileActions we return a proxy over the real v1 actions emulating a v2 action (to simplify the server code).

This way an app using files v3 work with 28,29,30,31 as per our deprecation rules (we had this discussion with management at the Nextcloud conference).
Apps using v4 will only work with 31+ but that is ok as long as v3 also works with 31,32 and 33. With 34 we can drop v3 support.

---

Context:
There is no reason to not support a server version, features can be conditionally using capabilities.
Binding a library to a server version removes all benefits from using a library.
I think we can do breaking changes like this and release a new major, but should make sure it still works with the other Nextcloud versions by having so

[Pytal]

Using 1 or 2 parameters before a context object in a function declaration does not seem that bad to me IMHO, any reason why we should never do this @skjnldsv?

[Pytal]

Why not simply

Suggested change

	nodes: [Node],
	node: Node,

?

[Pytal]

Suggested change

	context: Folder,
	folder: Folder,

Calling the folder context inside the context object seems confusing to me 😵

We should use "context" only for context objects

[skjnldsv]

it's to do a clear separation between the nodes. So we know folder isn't the subject of this action

[skjnldsv]

Using 1 or 2 parameters before a context object in a function declaration does not seem that bad to me IMHO, any reason why we should never do this @skjnldsv?

Because it just looks weird to me.
It's like mixing two syntaxes that have nothing in common, like spaces and tabs 😁

From a clean declaration perspective, I would agree with
function(path, options = {})
function(path, folder, view...)
function(options = {})

But mixing something like function(path, view, dir, options = {}) seems incoherent to me.
To prove my point, and assuming there is no issue with mixing both, then why do this feels worse? function(options = {}, path, dir) or even worse: function(path, options = {}, view, dir) 🙈

But more importantly, I like to be consistent across our APIs here, and considering we have multiple APIs that do similar approaches, like FileAction, NewFileMenu, Views..., I think we should stick to one type of pattern here. That way it's easy to know what to expect when you work with the @nextcloud/files library.

This is why I was really against #1113
PS: #1135