README: relocate update API instructions and example

[etungsten]

The instructions and example for using the update API is somewhat long and is currently cluttering the main README. Users shouldn't need to care about how to use the update API if they've already deployed brupop. If users are going through the trouble of reaching the host via host-containers to update the OS, they most likely would only care for the single step updog update command.

Issue number:
N/A

Description of changes:

Author: Erikson Tung <[email protected]>
Date:   Mon Sep 21 14:28:31 2020 -0700

    README: relocate update API instructions and example
    
    Relocates update API instructions, diagrams and example from the main
    Bottlerocket README to the update system documentation.

Note: please review changes using the rich diff

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[samuelkarp]

We don't have an equivalent of brupop for ECS today. The update API is available in the control container (via SSM), but updog is only available in the admin container. With this reorganization, would you recommend that folks using the ECS variant enable the admin container to use updog instead of the update API via SSM?

[etungsten]

We don't have an equivalent of brupop for ECS today. The update API is available in the control container (via SSM), but updog is only available in the admin container. With this reorganization, would you recommend that folks using the ECS variant enable the admin container to use updog instead of the update API via SSM?

I think it would be better if users don't need to directly interact with updog or the update API. I consider this change as a way to hide "implementation details" so to speak. If people want to update via SSM, the instructions are still available; The instructions just won't be in the top level Bottlerocket readme and will instead be one more click away.

Ideally we would have a helper script that does all the necessary API calls with a single invocation. Once such a tool is available, we can document its usage in the top level documentation.

I think it does make sense to document the current recommended way to update bottlerocket ECS hosts. How do you feel about adding an additional section for that under the Updates heading and have it reference the Bottlerocket API?

[etungsten]

Addresses @tjkirch 's comments.

[tjkirch]

I do think we should clarify ECS update properties, but I think it can be separate.