INIT integration: define `InitConfig` model

[angela-tran]

As previously alluded to in #4010 (comment), we need a model to store the details for connecting to Collect.js for tokenization and to MOBILEvario for registration.

For Collect.js. we know we need:

• a URL to the script, which can be used for any agency and environment
• an API key, which is agency-specific and environment-specific

For MOBILEvario, we know we need:

• a base API URL, which is agency/region-specific and environment-specific
• the header value for Basic HTTP Authentication, which is also agency/region-specific (as a function of it being specific to an API instance) and environment-specific

The definition of InitConfig should take all that into consideration and use patterns from LittlepayConfig and SwitchioConfig. It should also define its own ModelAdmin subclass and honor the same add/change/delete/view permissions as the LittlepayConfig/SwitchioConfig models.

Acceptance Criteria

• InitConfig model is defined with respect to the details listed above
• InitConfig models can be created / deleted / viewed / changed in Benefits Administrator with the expected permissions respected for our user types of superuser, Cal-ITP staff user, and transit agency staff user
• Sample fixtures updated
• Shared LastPass fixtures updated

Additional context

This is all based on our conversations with the INIT team in the context of implementing this for PSTA and their riders. We understand that other agencies that use INIT may not use Collect.js for tokenization and that the MOBILEvario API instances for those agencies may use different mechanisms for authentication. We recognize that the InitConfig we define in this task may not work as-is for the next INIT integration, and that is ok.

[jgravois]

the header value for Basic HTTP Authentication

i chewed on this a bit this morning and my instinct is that we'd be better served to store the username as a plain text field and the password as a keyvault secret and leave it to the app to base64 encode the appropriate header at runtime.

not a hill i'd die on, but it feels less-cryptic/more maintainable to me than supplying a base64 encoded string in a keyvault secret.

i think i may also just be hopeful that when we're implementing a second INIT configuration someday we'll be able to distinguish vintages via the authentication mechanism itself.

for example: we could add a radio of known auth types and only require username/password when 'basic auth' is selected.

happy to talk more about this face to face. i'm open to what you proposed here too.

[thekaveman]

the header value for Basic HTTP Authentication

i chewed on this a bit this morning and my instinct is that we'd be better served to store the username as a plain text field and the password as a keyvault secret and leave it to the app to base64 encode the appropriate header at runtime.

I'd agree with this approach, and the hope that it leads to something more generic down the line.