Fix spelling of namespaceMap

[phil-davis]

Description

When trying to login, and using PHP 8, I see in data/owncloud.log

{"reqId":"l9hXAPcOXzVrL00eKrhJ","level":3,"time":"2023-08-25T08:06:01+00:00","remoteAddr":"192.168.0.12","user":"joan","app":"PHP","method":"PROPFIND","url":"\/remote.php\/dav\/files\/joan\/","message":"Creation of dynamic property Sabre\\DAV\\Xml\\Service::$namespacesMap is deprecated at \/home\/phil\/git\/owncloud\/core\/apps\/dav\/lib\/Connector\/Sabre\/TagsPlugin.php#109"}

That is because the name of the property is not namespacesMap, it is namespaceMap.

The typo has been around for a long time in these 2 files - SharesPlugin.php and TagsPlugin.php
For example, see https://github.com/owncloud/core/pull/20931/files
It is correct in apps/dav/lib/Connector/Sabre/FilesPlugin.php

This PR fixes the typos.

I wonder what behavior this will fix?

How Has This Been Tested?

CI

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Database schema changes (next release will require increase of minor version instead of patch)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:
• Changelog item, see TEMPLATE

[phil-davis]

@jvillafanez @DeepDiver1975 the existing unit tests and acceptance tests all pass with and without this fix.
What behavior might be improved by fixing this typo in the namespaceMap property name?

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[jvillafanez]

I'd bet that a lot of plugins set the right namespace. Basically, each plugin would be overwriting what the previous one set, it's just that all of them set the same value. When the code runs through the plugin, it would use the right namespaceMap variable, which was set by a different plugin. At least this would explain why there is no change in the behavior and why it worked before.