spacemanager: unknown message have to be sent to Poolmanager

as SpaceManager works as a proxy, not all messages handled as
expected.

Ticket: 7844
Acked-by: Gerd Behrmann
Target: trunk, 2.6
Require-book: no
Require-notes: yes
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
libs: update jpnfs to 0.5.1

with following bug fixes and improvements:

- support for old file handles, which will allow to update nfs server without
  remount of existing clients (important for backtort to 2.2).

- reject mount from clients which do not have any export entries.
- respect root user if no_root_squash option is specified in exports file

  [3eb23ef] vfs: fix no_root_squash exports
  [5c12e5d] vfs: support old file handles
  [694da2f] vfs: construct new file handles from old one
  [513d265] test: add unit test for FileHandle and FileHandleBuilder
  [56d803b] nfsv4: consult export file on getRootInode()

Acked-by: Gerd Behrmann
Target: trunk, 2.6
Require-book: no
Require-notes: yes
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
nfs: return NFSERR_DELAY if we can't kill mover

If mover takes to much time to finish, then we will simply return OK.
In most cases this can go well. Nevertheless, it checksumming is
enabled, then file will be unavailable and file size still will be 0.

To solve this,  we return NFSERR_DELAY and enforce client to retry.
The problem here is to return NFSERR_IO if pool is unavailable.

Observed at DESY on transfer of big files
( measured checksumming seed is 1.6GB/s )

Acked-by: Gerd Behrmann
Target: trunk, 2.6
Require-book: no
Require-notes: yes
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
libs: Upgrade to JGlobus 2.0.6-rc3.d

Addresses a compatibility issue with some versions of curl and other
clients that send empty SSL messages.

Target: trunk
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: http://rb.dcache.org/r/5659/
(cherry picked from commit 45c172f2602dde104b2cb31c0caaad923aac596e)
Merge pull request #97 from gbehrmann/fix/2.6/rb5659

libs: Upgrade to JGlobus 2.0.6-rc3.d
[maven-release-plugin] prepare release 2.6.3
[maven-release-plugin] prepare for next development iteration
gplazma2-grid: Fix user name regression in authzdb plugin

Addresses the issue that authzdb may add a second UserNamePrincipal and thus
cause the validation phase of a login to fail. This is a regression introduced
in 2.6.1.

The patch restores the old behaviour. The logic is not exactly beatiful, but
given that space manager relies on authorization by user name, it makes sense
that the user name is consistent with the UID. Hence if UID is selected by
something different that user name, then we have to replace the user name.

Target: trunk
Request: 2.6
Require-notes: yes
Require-book: no
Patch: http://rb.dcache.org/r/5660/
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
(cherry picked from commit 0b075daae5204b3ae8d7cfae2d0a72b748e6e57a)
Merge pull request #100 from gbehrmann/fix/2.6/rb5660

gplazma2-grid: Fix user name regression in authzdb plugin
[maven-release-plugin] prepare release 2.6.4
[maven-release-plugin] prepare for next development iteration
Merge remote branch 'main/2.6' into feature/2.6/billing_soa
Merged master patch http://rb.dcache.org/r/5670