enhancement: add sse service skeleton

[fschade]

Description

So far, SSE has only been used to exchange content type messages between the server and the client.
In order to be able to send more content (and context) to the client, we have moved the endpoint to a separate service and are now also using it for other notifications like:

• notify postprocessing state changes.
• notify file locking and unlocking.
• TBD

Related Issue

• Requirement for: show file-locking information web#6682

Motivation and Context

First SSE POC was build as part of our christmas hacking and is used as a content messaging (no context) layer only at the moment, this is nice but does not show or use the whole potential of that endpoint.

To do so, and also make our clients more interactive (RIP F4), we start to use it for other notifications more and more.
For the moment we should not rely on SSE exclusively for business critical communications, that's why we're going on two tracks for the moment.

How Has This Been Tested?

• test environment:
• test case 1:
• test case 2:
• ...

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[fschade]

@kobergj, skeleton only right now, feel free to take over, i'm back on monday.
@lookacat FYI

[kobergj]

• Provide a README.md for that service in the root folder of that service.
  • Use CamelCase for section headers.
• For images and example files used in README.md:
  • Create a folder named md-sources on the same level where README.md is located. Put all the images and example files referenced by README.md into this folder.
  • Use absolute references like https://raw.githubusercontent.com/owncloud/ocis/master/services/<service-name>/md-sources/file to make the content accessible for both README.md and owncloud.dev
    bad <img src="https://github.com/owncloud/ocis/blob/master/services/graph/images/mermaid-graph.svg" width="500" />
    good <img src="https://raw.githubusercontent.com/owncloud/ocis/master/services/graph/images/mermaid-graph.svg" width="500" />
• If new CLI command are introduced, that command must be described in readme.md.
• If new global envvar is introduced, the name must start with OCIS_.
• Add the service to the makefile in the ocis repo root.
• Make the service startable for binary and individual startup:
  • For single binary add service to ocis/pkg/runtime
  • For individual startup add service to ocis/pkg/commands
• Add the service to .drone.star to enable CI.
• Inform doc team in an early stage to review the readme AND the environment variables created.
  • The description must reflect the behaviour AND usually has a positive code quality impact.
• Create proper description strings for envvars - see other services for examples, especially when it comes to multiple values. This must include:
  • base description, set of available values, description of each value.
• When suggestable commits are created for text changes and you agree, collect them to a batch and commit them. Do not forget to rebase locally to avoid overwriting the changes made.
• If new envvars are introduced which serve the same purpose but in multiple services, an additional envvar must be added at the beginning of the list starting with OCIS_ (global envvar).
• Ensure that a service has a debug port
• If the new service introduces a new port:
  • the port must be added to port-ranges.md and to the readme.md file.
• Make sure to have a function FullDefaultConfig() in pkg/config/defaults/defaultconfig.go of your service. It is needed to create the documentation.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

7.2% Coverage
15.4% Duplication