Add initial Protobuf support

[DrusTheAxe]

Add support for Google's Protocol Buffers (aka protobuf)

Using protobuf requires 3 components:

1. protoc.exe -- 'Compiles' *.proto files generating *.pb.cc and *.pb.h code
2. headers -- Needed to compile generated *.pb.cc
3. libs -- Needed to link compiled bits from 2

Google provides a nuget containing a compiled protoc.exe but doesn't make headers or libs available via nuget. TL;DR we create a nuget for our use (Microsoft.WindowsAppSDK.Protobuf.3.21.12.nupkg). Details of what, why and how are in tools\nuget\protobuf\README.md.

TL;DR Developers working in WinAppSDK only need to know there's a nuget providing protobuf support. The messy details how to create that are only relevant to the developer creating the nuget (moi) or future devs if/when a new version is needed.

Added KozaniProtocol containing Kozani's protobuf messages and related definitions. The purpose of KozaniManageProtocol project is to contain all of Kozani's protobuf definitions and compile them to produce the generated code for use by other projects.

Updated KozaniManager to consume the protobuf code from KozaniProtocol and added wrappers showing how to use it.

Updated KozaniRemoteManager to reference to consume the protobuf code from KozaniProtocol.

General structure of our protobuf usage:

1. Define a message in KozaniProtocol.

• Split up by functional roles across *.proto files e.g. Kozani.Activation.proto for activation, Kozani.Process.proto for process management (e.g. if TaskManager kills local KozaniHostRuntime.exe we need to send message to server to terminate the associated back end process), etc.
• Any sort of 'synchronous communication' would involve a pair of request+response messages. KozaniManager sends 'request' to server and KozaniRemoteManager sends a related 'response'.
• The 'cookie' field is an example of a correlating id to match a request with a response. A 'conversionid', 'channelid', etc are other examples how to xref 2+ messages together into a larger context.

2. Define a namespace with functions that internally use protobuf messages

• Keep all protobuf usage internal to code using them. Protobuf is an implementation detail. Provide appropriate strongly typed functions for callers to drive activity which internally happen to use the protobuf generated code.
• If you need context spanning multiple messages you can create a class with methods which internally use protobuf messages, plus additional attributes for any additional data needed for the context.

3. Serialize messages to std::string

• Protobuf can serialize messages to std::string or std::ostream. NOTE: The serialized data's just bytes, string is just a convenient container to pass the data around.
• std::string is recommend when serializing a message to bytes.
• std::string or std::istream is recommended when deserializing a message from bytes. Large messages may be more efficient via std::istream; either works well enough for small messages so use whichever is more convenient.

4. Always encode strings as UTF8 before serialization.

• Protobuf expresses message string fields as std::string. It does not do wide<->narrow conversions for you (unlike, say, SQLite) - that's the developer's responsibility. If you have a wide string (std::wstring, PCWSTR, HSTRING, etc) convert it to a UTF-8 string before assigning it to a protobuf field. Use functions in \dev\common\Microsoft.Utf8.h to convert wide->utf8 e.g.

PCWSTR appUserModelId{ L"LolzCatzVidz" };
const std::string appUserModelIdUtf8{ ::Microsoft::Utf8::ToUtf8(appUserModelId) };

• When deserializing wide strings from protobuf serialized bytes don't forget to convert the UTF-8 bytes to a wide string. Use functions in \dev\common\Microsoft.Utf8.h to do this e.g.

Some::Protobuf::Message::Kitteh kitteh;
kitteh.ParseFromString(stream_containing_serialized_bytes);
const std::wstring name{ kitten.get_name() };

5. Avoid making classes inherit from protobuf's generated classes.

• Protobuf docs counsel against against inheriting and extending the generated classes. Treat protobuf's generated classes as structs of data you can access but not extend (use composition esp private composition, not inheritance).

6. We use protobuf as a static library.

• Protobuf can provide support code via libprotobuf.dll but recommends against it as that must have a compatible version as the generated code. To minimize complications we use protobuf as a static lib. This may be revisited in the future.

Everything compiles and links. dev\Kozani\KozaniManager\main.cpp has an example serializing a protobuf message to bytes (as a std::string). Changing and extending that for all the rest of our functionality and likewise parsing bytes to protobuf messages in KozaniRemoteManager (or vice versa) is left as an exercise for the reader :-)

[rhuang-msft]

Looks good to me.

[DrusTheAxe]

/azp run

[azure-pipelines]

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.