Aquire lock before calling getTunnelDetails

[emagiz]

Note: Logically it si reasoned to fix the linked issue, but feedback on this PR is much appreciated.

Tries to closes #11787

Changes:

As per note above getTunnelDetails, a lock must be aquired before calling the method. In SetTunnelStatusToRequired this does not happen, and can potentially cause #11787. This PR reorders the the calls to precent the method being called without the lock

[andres-portainer]

This fix was already introduced in the PR #11378, but it has not been merged yet: https://github.com/portainer/portainer/pull/11378/files#diff-fb151cd39e19bd6f87d9c886ac723e3d1921d1ce3d6c8c8346984416fb1488c3R149.

[emagiz]

@andres-portainer Do you think this could potentially be the cause of the linked issue? We're trying to reproduce the issue, but that seems very though. If you say this could be the cause of the issue we can atleast proceed with it.

[andres-portainer]

We will be looking into this issue but I don't currently think that the misplaced lock could be the problem.

[emagiz]

We've done some more testing, and the issue can be a combination of it, and the use of the endpointId parameter in the PUT /stack/{id} call. We've seen that exactly shows what we've seen in portainer during the problems

EDIT: It seems that permissions block from deploying the stack wrongly using endpointId