proposal(www): allow providers to make access keys shareable.

[daniellacosse]

Similar to https://github.com/Jigsaw-Code/outline-client/pull/1830, this PR extends the extra field now with the ability for providers to enable end users to share their access keys with others:

{
  host: '10.0.0.24',
  port: 123,
  method: 'chacha20-ietf-poly1305',
  tag: 'Fake Unreachable Server',
  extra: {
     share: true
  }
}

#1830 and this PR in tandem enable the following scenario:

[codecov[bot]]

Codecov Report

Attention: 18 lines in your changes are missing coverage. Please review.

Comparison is base (69bdfd7) 32% compared to head (f2ac0af) 32%.

Files	Patch %	Lines
src/www/app/app.ts	0%	15 Missing :warning:
...servers_view/server_list_item/server_card/index.ts	0%	3 Missing :warning:

Additional details and impacted files

@@                            Coverage Diff                             @@
##           daniellacosse/provider_message_and_contact   #1836   +/-   ##
==========================================================================
- Coverage                                          32%     32%   -1%     
==========================================================================
  Files                                              45      45           
  Lines                                            2620    2637   +17     
  Branches                                          342     347    +5     
==========================================================================
+ Hits                                              859     861    +2     
- Misses                                           1761    1776   +15     

Flag	Coverage Δ
apple	15% <ø> (ø)
ios	15% <ø> (ø)
maccatalyst	15% <ø> (ø)
macos	15% <ø> (ø)
unittests	32% <5%> (-1%)	:arrow_down:
www	40% <5%> (-1%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[sbruens]

For this and #1830, if we're going to use the extra value for different configuration options, should we avoid non-object types at the top-level of extra to avoid it becoming a long grab-bag list of properties? I could imagine the sharing options to expand in future, such that a separate sharing key:value configuration object would be useful:

{
  "host": "10.0.0.24",
  "port": 123,
  "method": "chacha20-ietf-poly1305",
  "tag": "Fake Unreachable Server",
  "extra": {
    "sharing": {
      "enabled": true
    },
    "contact": {
      "messageContent": "We are experiencing increased demand.",
      "messageType": "warning",
      "email": "[email protected]"
    }
  }
}

[daniellacosse]

For this and #1830, if we're going to use the extra value for different configuration options, should we avoid non-object types at the top-level of extra to avoid it becoming a long grab-bag list of properties? I could imagine the sharing options to expand in future, such that a separate sharing key:value configuration object would be useful:

{
  "host": "10.0.0.24",
  "port": 123,
  "method": "chacha20-ietf-poly1305",
  "tag": "Fake Unreachable Server",
  "extra": {
    "sharing": {
      "enabled": true
    },
    "contact": {
      "messageContent": "We are experiencing increased demand.",
      "messageType": "warning",
      "email": "[email protected]"
    }
  }
}

For this and #1830, if we're going to use the extra value for different configuration options, should we avoid non-object types at the top-level of extra to avoid it becoming a long grab-bag list of properties? I could imagine the sharing options to expand in future, such that a separate sharing key:value configuration object would be useful:

{
  "host": "10.0.0.24",
  "port": 123,
  "method": "chacha20-ietf-poly1305",
  "tag": "Fake Unreachable Server",
  "extra": {
    "sharing": {
      "enabled": true
    },
    "contact": {
      "messageContent": "We are experiencing increased demand.",
      "messageType": "warning",
      "email": "[email protected]"
    }
  }
}

I -believe- extra values are meant to be strings, but there's nothing stopping us from passing through base64'd json i suppose!