Remove incorrect use of TryLock for initial delay state in TUF autoupdater

[RebeccaMahany]

I didn't add TryLock correctly here before -- this had the consequence that a request to pin a version or autoupdate immediately outside of the initial delay would then block subsequent requests to pin a version or autoupdate immediately.

In this PR, I've pulled it out in favor of a timestamp; we set the timestamp in NewTufAutoupdater rather than in Execute to avoid data races in tests (or a mutex added only to address data races in tests).

[directionless]

It's probably okay, but since our only usage is:

	if ta.isInInitialDelay() {
		ta.slogger.Log(context.TODO(), slog.LevelWarn,
			"received update request during initial delay, discarding",
		)
		// We don't return an error because there's no need for the actionqueue to retry this request --
		// we're going to perform an autoupdate check as soon as we exit the delay anyway.
		return nil
	}

I'd rather move away from mutexes and all all the potential locks. What if we recorded the time we should be locked until, and then time compared? I guess that fails if the clock is updated mid delay.

I guess one approach would be to keep our own program runtime. But that feels like a lot of work.

So maybe this is the simplest approach

[RebeccaMahany]

@directionless I like that idea too, but setting something like ta.initialDelayEnd = time.Now().Add(ta.knapsack.AutoupdateInitialDelay()) at the beginning of Execute will still require a mutex to avoid data races during the tests 😕 -- that's the only reason I preserved the mutex.

[directionless]

@directionless I like that idea too, but setting something like ta.initialDelayEnd = time.Now().Add(ta.knapsack.AutoupdateInitialDelay()) at the beginning of Execute will still require a mutex to avoid data races during the tests 😕 -- that's the only reason I preserved the mutex.

Hrm... If we set it at create time, we could skip the mutex... Might not be worth it. Fun thought exercise