Stop relying on deprecated /computer/${NAME}/jenkins-agent.jnlp endpoint

[basil]

The Swarm plugin currently relies on this deprecated endpoint to retrieve the secret (MAC) in the following sequence of events:

1. Swarm client authenticates with username and API key (or password + CSRF crumb) to call the endpoint to create the Swarm agent (this requires Agent/Create)
2. Swarm client invokes deprecated /computer/${NAME}/jenkins-agent.jnlp endpoint (this requires Agent/Connect) to get the secret
3. Swarm client vectors into Remoting with -url, -name, and -secret as in the non-Remoting case

This PR eliminates step 2 by having step 1 also return the secret. Thus step 2 can be skipped and we can proceed to step 3.

I think it is safe to return the secret in Step 1 because it is behind Agent/Create.

This PR has a nice bonus of reducing the permissions needed for the Swarm user, which I think makes more sense. The existing Agent/Connect permission requirement was a side effect of the implementation (step 2) and never made much sense to begin with.

Migration

I'm keeping the old code around so that the new client can still be used with the old controller-side plugin during a transition period. This way users can start upgrading the client right away without having to worry about upgrading all of their controllers in lockstep. Eventually, when most installations are using the new version of the plugin on the server side, I'll rip out the old code from the client side.

Testing done

The permissions are tested in an existing integration test, and I verified that Agent/Connect is no longer required as expected.

I also verified that a fake version of Remoting that throws an IllegalStateException whenever the deprecated functionality is invoked never hit the deprecated code path when using this PR.

[basil]

CC @jenkinsci/core-security-review

[yaroslavafenkin]

Looks fine security wise AFAICT.

This seems to introduce sort of an inconsistency, because in core you need Agent/Connect permission to see the secret, while with this PR it'll be Agent/Create for Swarm agents. But from the PR description I get an impression that it's a conscious decision from you and that you understand the implications.

[basil]

Looks fine security wise AFAICT.

This seems to introduce sort of an inconsistency, because in core you need Agent/Connect permission to see the secret, while with this PR it'll be Agent/Create for Swarm agents. But from the PR description I get an impression that it's a conscious decision from you and that you understand the implications.

I don't feel too strongly about this: would you prefer that I put the endpoint behind both Agent/Connect and Agent/Create permissions? That would maintain consistency with core, and it shouldn't break compatibility either.

[yaroslavafenkin]

Looks fine security wise AFAICT.
This seems to introduce sort of an inconsistency, because in core you need Agent/Connect permission to see the secret, while with this PR it'll be Agent/Create for Swarm agents. But from the PR description I get an impression that it's a conscious decision from you and that you understand the implications.

I don't feel too strongly about this: would you prefer that I put the endpoint behind both Agent/Connect and Agent/Create permissions? That would maintain consistency with core, and it shouldn't break compatibility either.

Yes, that would be ideal to have both.

[basil]

I restored it in commit 977f5d0 and ensured that the tests failed when Agent/Connect was not present and passed when Agent/Connect was present (i.e., as the tests run on the main branch right now).