Add start_time and minimum_execution_duration fields to actions

[michel-laterman]

What is the problem this PR solves?

Fleet-server should be able to inform agents of actions that are scheduled to start at a later time.
Fleet-server should also be able to spread the start time that different agents within the window of start:expiration.

This should help with ensuring that hundreds (or thousands) of agents don't exhaust the network when upgrading (for instance).

How does this PR solve the problem?

Add start_time and minimum_execution_duration fields to action
definition. When start_time and expiration are defined the fleet-server
will schedule agent actions within [start:expiration], if the
minimum_execution_duration s defined the scheduling range is
[start:expiration-minimum_execution_duration]. An agent's scheduled time
within the range depends on the agent id's position within the list.

How to test this PR locally

See testing in elastic/elastic-agent#419

Checklist

• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• [ ] I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Related issues

• Closes Fleet server should be able to schedule future actions #1380

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-05-24T02:17:56.953+0000

• Duration: 11 min 36 sec

Test stats 🧪

Test	Results
Failed	0
Passed	304
Skipped	1
Total	305

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[mergify]

This pull request does not have a backport label. Could you fix it @michel-laterman? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v/d./d./d is the label to automatically backport to the 7./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

[AndersonQ]

I left a question. But LGTM

[ph]

requires elastic/elasticsearch#8616 right?

[ph]

Shouldn't we move the validation to the original unpack of the action instead? If there is an unserialization error this means that the contract between fleet and fleet-server is broken. I don't think we should even try to process that event.

[michel-laterman]

To summarize a quick conversation. We should catch this on the json unpacking, however the model.Action is generated by elastic/go-json-schema-generate which does not support mapping a (json) string/date-time to go's time.Time. The upstream generator we forked our code from has this as an open issue a-h/generate#69 so if we get around to it we should contribute it back

[ph]

@michel-laterman Changes LGTM, it's there a way to test it end to end with Elasticsearch with an integration test?

[mergify]

This pull request is now in conflicts. Could you fix it @michel-laterman? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b rolling-update upstream/rolling-update
git merge upstream/main
git push upstream rolling-update

[mergify]

This pull request is now in conflicts. Could you fix it @michel-laterman? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b rolling-update upstream/rolling-update
git merge upstream/main
git push upstream rolling-update

[mergify]

This pull request is now in conflicts. Could you fix it @michel-laterman? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b rolling-update upstream/rolling-update
git merge upstream/main
git push upstream rolling-update