dbus: Remove the upper limit on try timeout (LP: #1967084)

[schopin-pro]

Also, increase the default to 10s.

If the caller sees fit to specifiy a 30s timeout for their try call, it
stands to reason to respect that decision, as they (probably) know
better.

This issue came up in the Core testsuite, where the netplan
configuration step failed because netplan try took 6s, cf
LP: #1967084. Their DBus call specifies a timeout of 300s, but the call
failed after a "relatively short time", which was this internal timeout.

Note that the mere fact that netplan try takes more than 5s on such a
simple configuration is probably due to the following patch:

https://git.launchpad.net/ubuntu/+source/netplan.io/tree/debian/patches/0006-cli-apply-give-some-extra-time-for-networkctl-reload.patch?h=applied/ubuntu/focal-updates

Since the bridge is empty, it might be in a "configuring" state forever.

Granted, that's not something one would do on production systems,
however creating an empty bridge interface is routinely done in test
suites, including our own.

Checklist

• Runs make check successfully.
• Retains 100% code coverage (make check-coverage).
• (Optional) Closes an open bug in Launchpad.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.07%. Comparing base (d692ce7) to head (c72bf8c).
Report is 649 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #271   +/-   ##
=======================================
  Coverage   99.07%   99.07%           
=======================================
  Files          61       61           
  Lines       10864    10864           
=======================================
  Hits        10764    10764           
  Misses        100      100           

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

[sil2100]

In principle this sounds fine. At least right now I can't think of a reason why we would only allow overriding the timeout but only up to the default value that we provide. So +1.

[sil2100]

After this is merged, I'm thinking of cherry-picking this fix and including it in the ubuntu-image PPA used by the coreXX builds. But this depends on the severity - if @mvo5 thinks it's not needed, then we can just wait for this to go through the usual SRU route or the root cause being fully identified.

[mvo5]

Thanks, this looks fine. Let's not forge/ignoret the other findings in LP: 1967084 though after merging this, I think there is more to this than just increasing the timeout :) (either on the snapd or the netplan side, a bit unclear to me at this point)